Use Continuous Backlog Grooming to Refine Agile Requirements
Think for a moment about the things that can really slow down an agile team. For example, does your team have to stop to get user story details before your developers can begin coding? Are your user stories ambiguously defined and not quite ready to implement at the time you need them?
Having to stop to obtain those details prevents your team from maximizing development time during the sprint. This slowdown is usually caused by what I call “chunky” user stories—those that are too big or too vague to begin development. So your team spends way too much time in sprint planning trying to obtain those details or, worse, puts them off until development actually begins. Now you see where the idea of continuous backlog grooming begins to make sense.
Continuous backlog grooming means systematically refining your user stories: breaking up larger stories, obtaining detailed requirements for sufficiently small stories, writing the requirements in terms of acceptance criteria and acceptance tests, and sharing and refining these details with the team. An approach I have used successfully to structure continuous backlog grooming is called acceptance test-driven development (ATDD).
ATDD is a process that allows an agile team to quickly refine user stories prior to development. It uses traditional requirements techniques to capture the details and involves the whole team just when the details are needed. ATDD basically allows everyone on the team to begin testing at the same time—prior to writing a single line of code.
ATDD is not a new idea. Don Gause and Gerald Weinberg described how to use acceptance tests to obtain and refine requirements in their 1989 book Exploring Requirements: Quality Before Design. They wrote, “[O]ne of the most effective ways of testing requirements is with test cases very much like those for testing a completed system.” They revealed this insight long before the Agile Manifesto was written.
Through the years the industry has termed similar concepts “story test-driven development” (Ken Beck, 1999), “scenario testing” (Cem Kaner, 2003), “specification by example” (Martin Fowler, 2004), and “conditions of satisfaction” (Mike Cohn, 2013), to name a few. In its present form, one of the best resources to get you started with ATDD is Elisabeth Hendrickson’s blog Acceptance Test Driven Development (ATDD): an Overview.
Sounds great, but what about this idea of “continuous”? Who has time for that? Let me suggest that you tap into the talents of your business analysts, customer advocates, or test leads and coordinators to learn and apply ATDD. These folks typically have requirements elicitation skills and can take the load off developers who are usually tasked with getting the details. Their upfront research, interviews, and detailed acceptance criteria and acceptance tests will help your team accelerate sprint planning—just when you need it.
Susan Brockley is presenting the session Jump Start Agile Testing with Acceptance Test Driven Development at STARCANADA 2017, October 15–20 in Toronto, Ontario.
