Story Refinement

52 team-story-refinement

After Story Refinement, the product owner and development team will have a shared understanding of what each user 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.

Explore More.

Related Mindset:

Lean-Agile

Segment:

Team

Inputs:

A collection of user stories, team commitments, and mapped dependencies

Outputs:

Detailed user stories with clear acceptance criteria which are ready for implementation

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:

Common Pitfalls

Simple recognition that Story Refinement is a crucial step in the success of an agile team is vast improvement over stories simply being handed off to the development team with no discussion.

However, the process is even more effective when avoiding these common pitfalls:

  • Poor acceptance criteria: Any good user story should be accompanied by good acceptance criteria that expresses in detail the product owner’s expectation for how the system/product should behave when the story is complete. In the absence of good acceptance criteria, developers may make incorrect assumptions about how a story is expected to work, and QA testers will not accurately verify that the story works as desired.
  • Insufficient visual detail: For user stories which involve creating new user interface or altering existing interface, often it is difficult to capture a product owner’s expectations simply with narrative text. Add wireframes, design compositions, and motion/transition guides where appropriate to ensure that everyone understands not only how the new functionality will work but also how it will look. The supplemental visuals become an element of the acceptance criteria.
  • Undocumented exception cases: Frequently, stories will address the “happy path” of new functionality. For example, in a hotel reservation system, a story might describe allowing a user to update an existing reservation. However, what happens if the user attempts to update too close to the date of the reservation and incurs a cancellation fee from the hotel? Should the user be warned before attempting to edit the reservation? Should they be prompted to accept the cancellation fee before saving changes? Should the edit simply be rejected with an explanatory message? During Story Refinement, make an effort to think not only of the ideal path but of how to handle exceptional scenarios as well. Doing so will reduce development time and defects in the long-run.

Tools

Most mature issue tracking tools such as Atlassian JIRA and Visual Studio Team Services provide good user story templates with discrete areas to capture the user story narrative, acceptance criteria, and attachments such as wireframes and designs which support the story.

References