Backlog Refinement

Be prepared for multiple upcoming sprints

  • Visualize
  • Change needed for architecture or technical design?

Why

The goal of Backlog Refinement[1] is to be prepared for the upcoming sprints.

Prepare for success

  • Product Owner should have ordered the Product Backlog before the session. This makes clear which user stories on the top of the backlog are not actionable yet. Those must be refined first.
  • Product Owner[2] should be prepared on the user stories that will probably be refined during the session. This might require cooperation with certain stakeholders or team members.
  • Plan the backlog refinement session halfway the current sprint (in preparation of the next sprints), and invite everyone who is needed: Product Owner, Development Team and possibly some key stakeholders.

How

User Stories are refined one by one, most important one first. Per user story[3], follow this format:

  • Product Owner (or key stakeholder) explains the business- or user goal (the why) of the story. Team ask questions and discusses. Any clarification or decision is noted in as part of the story details (e.g. acceptance criteria).
  • Product Owner (or key stakeholder) explains the preferred functional solution (the what) of the story. Team ask questions and discusses. Any clarification or decision is noted in as part of the story details (e.g. acceptance criteria).
  • If the story is considered too big by the team, Product Owner and team discuss options for splitting the story in multiple stories, and split it. Product Owner orders the new stories. More often than not, part of the original story gets a low priority on the backlog.
  • Once it is clear for the team why and what is asked, planning poker is used to discuss the how. This also results in a relative estimate (story points).

Additional notes:

  • Certain bugs might also require refinement, especially if the desired behavior is not clear.
  • To come from epics to user stories, we prefer having a co-preparation session. But sometimes (for relatively small or straightforward epics) a backlog refinement session could suffice for this as well.
  • Best practice is to refine enough user stories for 1 to 2 sprints in advance. However, there might be valid reasons to deviate from this.

Definition of Done[4]

  • Prepared User Stories for refinement are actionable and estimated, ór
  • Timebox for the session has ended.

Real Life Example

At the beginning of the development of a mobile application there are a number of user stories written that are based on a wireframe. These stories are very high level and not actionable at this point and there are no acceptance criteria present. The team is about to start a new sprint and during the pre-scheduled refinement session some of the stories that need refinement are discussed. For a specific story, a stakeholder is invited into the meeting to clarify the rationale behind this story. The team challenges the design idea proposed by the stakeholder and comes up with a much simpler and better design proposal. The result is that the team has a mutual understanding of the requirements and the acceptance criteria are now noted in the user story. Based on this understanding a relative estimate is made and instead of five points, the story is now estimated at two points.

During another refinement meeting a different Kabisa team picks up a story about the connection of a webshop with a payment provider. The product owner believes this is a straight forward connection and the initial estimate was two points. During a discussion a different payment method is suggested and the team splits up the story into multiple smaller user stories. Together these smaller stories make up a larger amount of story points than the original two points. The product owner decides to pick only the stories with the most business value for the next sprint.

Notes

  1. Backlog Refinement - The goal of Backlog Refinement is to be prepared for the upcoming sprints.
  2. Product Owner - The Product Owner plays a crucial role in the development of a great software product. He or she is responsilble for maintaining the Product Backlog.
  3. User Story - A user story describes a functional goal from the perspective of an end-user. Who wants to do what with the product, and why?
  4. Definition of Done - A shared understanding of expectations that the Increment must live up to in order to be releasable into production. Managed by the Development Team.