Story Refinement is the process wherein raw user stories, which should capture the product owner’s vision for functionality and business value, are supplemented with additional detail or altered through a discussion with the development team.
Well-known software development and agile expert Martin Fowler notes the following reasons for engaging the development team in reviewing user stories1:
- Spotting inconsistencies and gaps between the stories
- Using technical knowledge to come up with new stories that seem to fit the product owner’s vision
- Seeing alternative stories that would be cheaper to build, given the technological landscape
- Split stories to make them easier to plan or implement
Story Refinement builds a shared understanding between the product owner and development team of the work to be done. This, in turn, helps to more accurately estimate the work to be done and avoid time spent implementing features which may not fully match the product owner’s goals. QA team members should come away from Story Refinement with a clear understanding of the story’s acceptance criteria, so they can confidently determine when each story is complete.
The Story Refinement process should establish:
- Granular detailed storiesFowler, Martin. “Conversational Stories” http://martinfowler.com/bliki/ConversationalStories.html: Often the first pass at a user story may be rather broad in scope and lacking in sufficient detail for a development team to confidently begin implementation. Where appropriate, stories should be broken down into discrete, small chunks of “value” for the customer. Details that surface during discussion of the story should be captured. Consider which of the granular stories are critical for the “minimal viable product”, critical for the feature to work, and which may be supplemental functionality building on the core user stories.
- Acceptance criteria: While the narrative description of a story provides valuable context for the story, the acceptance criteria are the standard by which developers and QA resources will gauge whether the story is properly implemented. These criteria, normally presented in list format, should detail what the user should expect to see in both normal and exception scenarios as they interact with the software.
- Dependencies: Discussion of each story should clarify any dependencies among the stories. These dependencies should be documented to guide the plan for implementing each story. In many cases, these dependencies should have already been identified in the Map Dependencies element, but they should be revisited and validated at this point.
- Estimates and prioritization: As the development team absorbs the details of a story’s purpose and acceptance criteria, they will be able to estimate the effort the story entails. This estimate is a crucial input to planning what work the team can commit to during each sprint. The product owner should also help prioritize stories, especially when there is more work than team capacity, based on business objectives.
After Story Refinement, the product owner and development team will have good shared understanding of what each story will contribute to the product functionality, the work required to deliver the story, and the criteria by which the story will be evaluated for completion.
For more information on User Stories and Enablers within the context of the Scaled Agile Framework®, review the following abstract: