Marcano on acceptance-test-driven development

When I met Antony Marcano, who runs the essential blog Testing Reflections, a year ago at STARWest in Anaheim, I immediately liked his views on agile testing. He published a very insightful article in Better Software this month on a topic that's been top-of-mind for me recently: Acceptance-Test-Driven Development (ATDD). I'll let him explain (emphases mine):

ATDD bridges the gap between an idea summarized in a user story and the implementation of that story. It helps elicit the detail behind the idea to make it better understood by both the customer with the idea and the cross-functional development team that will implement it. ...

Whenever we begin to discuss acceptance criteria, it’s safe to say the user story alone is not enough. To establish a shared understanding of a user story, the customer elaborates on the idea behind it by first outlining some acceptance criteria—often in terms of the new behaviors that the system will exhibit once the story is implemented. This is so that the team has a high-level view of the story’s real meaning. Programmers, testers, and the customer exchange examples of specific inputs and outputs that further clarify the scope of the user story. This results in refinements to existing acceptance criteria or additional criteria. During the iteration, programmers and testers work with the customer to draw out the detail required for them to expand outlined acceptance criteria into specific examples in the form of tests. From these tests, programmers infer the underlying rules that must be implemented. During this process, with the help of a variety of testing techniques, testers help to identify exception cases and reduce other example behaviors into equivalent cases. The result is a set of examples, expressed as automated acceptance tests. These tests are run and, since the feature isn’t implemented yet, they fail—as expected. For each of these automated acceptance tests, programmers implement enough of the software for the acceptance test to pass (ideally using TDD with unit tests). Once all the acceptance tests for a story pass, the story is done— almost.

(He goes on to note that the story's not "done" until exploratory testing -- another important practice -- happens.) It seems to me that ATDD goes a long way to solving many pains: knowing when "done" is, eliciting requirements, developing the right features first, etc.

Standups and communication

Communication is the first core value of XP. So how does your team communicate with each other? How well do you do it?

One way that our development teams communicate is via daily standup meetings. But what is a standup meeting, anyway? How about this definition: a self-organizing daily gathering to gain shared understanding of the state of our team, focus our day and remind ourselves that we're all in this together. As one comment on Ward Cunningham's wiki puts it, "Our aim is modest: to identify short-term obstacles. The agenda is minimalist: What does the day look like?" Some teams eschew standups because they’re not helpful; perhaps understanding the objectives can help you reshape your standup. How do you know if your standup meetings are effective? Here are some possible outcomes:

• Everyone knows what he or she is going to do -- and with whom -- as soon as the standup ends (rather than finding a pair partner or figuring out what to do after the meeting ends).
• Everyone understands where the team is on all the stories -- if an outsider were to ask you about any story, you could answer (rather than merely “the story I'm working on”).
• Everyone knows high-level problems facing the team for the day (rather than not knowing).
• Everyone has a sense of how complete the iteration is, and what needs to be done to "make it" (rather than being surprised on the last day).
• The team has decided to have breakout meetings to resolve specific problems (rather than try to solve bigger problems in the standup).
• Everyone knows what the team is pledging to accomplish for the day (rather than being unfocused).
  

If you're not accomplishing these, check out the standups article on Martin Fowler's site, which provides useful patterns and identifies "smells" for standups. Now for some best practices that we’ve seen around Asynchrony:

• Prompt start: The way a team starts its standup is indicative of the way the day will go; when everyone arrives on-time (or, heaven forbid, a minute early!) the meeting tends to have a snappier pace. Use a fun disincentive to cut down on lateness (e.g., tardy MFKR team members having to wear a PPE jumpsuit).
• Story-based: Rather than focusing on individual check-ins, the team talks about its progress in terms of stories. Facing the story posters on the board, the team talks about the unfinished stories in order of priority and how to complete them. The team can set a goal by determining which stories it will attempt to finish that day.
• Know what’s next: Before the standup meeting is over, know who your pair partner is (consult the pairing chart for help) and what task you’re going to work on, and go to it.