Product Backlog Refinement

The Product Backlog refinement is a continuous process to create actionable Product Backlogs, enabling a Scrum Team to run Sprint Plannings at a moment’s notice. Consequently, refinement is about creating alignment among all team members about the Why, the What, the How, and probably even the Who regarding the upcoming work for the Scrum team’s Product Goal. As a result, Product Backlog refinement is a critical success factor as it drastically increases the team’s capability to deliver valuable Increments regularly. 

The following 14 first principles describe in broad strokes the foundation of a successful approach to refinement.

The Purpose of the Product Backlog Refinement According to the Scrum Guide

The Scrum Guide mentions the refinement on several occasions related to Product Backlog management and the Sprint planning:

“During the Sprint, the Product Backlog is refined as needed.” 

“[Sprint Planning: What can be Done this Sprint?] The Scrum Team may refine these items during this process, which increases understanding and confidence.” 

“[Product Backlog items] usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items.”

“[Product Backlog refinement] is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.”

Source: Scrum Guide 2020.

The Product Backlog refinement is a continuous process to create actionable Product Backlogs, enabling a Scrum Team to run Sprint Plannings at a moment’s notice.

The Scrum Team accomplishes this level of proficiency by regularly refining Product Backlog items in small groups or with the whole Scrum Team, and not just once every Sprint as part of the Sprint Planning. The idea behind the refinement is to create a shared understanding with all team members of why a particular work item is valuable, what the Developers shall build, and how to realize the work technically. 

This competence of the Scrum team is critical to creating trust with the management and stakeholders by regularly delivering valuable Increments. 

While the Scrum Guide 2020 dropped the previous guidance on time allocation, it remains a practical rule that the Scrum Team should reserve up to 10% of its time for Product Backlog refinement.

In general, it is beneficial to structure the refinement process around questions such as:

• What items are no longer relevant?
• What items do we need to split?
• What items can we update with new information?
• Does this update change previous estimations?
• Has the priority of specific items changed?
• Do we have any new topics or learnings that haven’t yet been considered? (If yes, we need to capture these as new Product Backlog items.)

In my eyes, the following quote from Karl Popper perfectly describes the reason why Product Backlog refinement is a critical success factor for every Scrum team: 

“Always remember that it is impossible to speak in such a way that you cannot be misunderstood: there will always be some who misunderstand you.” 

(Source)

14 Success Principles of the Product Backlog Refinement

These are my 14 Product Backlog refinement first principles:

1. Refinement’s purpose: The end-stage of refinement is a shared understanding of the why, what, how, and probably who, paired with confidence on the Developers’ side that they can create the Product Backlog item in question within a single Sprint.
2. Duration: The refinement of a single Product Backlog item may take several rounds. Keep refinements short and frequent.
3. Continuous refinement: Product Backlog refinement is an ongoing activity, not just an isolated event of 60 minutes to rush through a checklist. Team members take time to refine Product Backlog items they are interested in working on, for example, when they learn something relevant to the task. Refining a Product Backlog item is a regular part of a Scrum team’s work during a Sprint.
4. “All hands on deck” is not required: Product Backlog refinement does not mean that all team members participate in all refinement activities all the time; it is opt-in for those interested in the respective Product Backlog items. 
5. Refinement is for everyone: The Product Owner shall strive to involve the entire Scrum team in the Product Backlog refinement process and not just rely on the “lead engineer” and a designer. The reason for an inclusive approach is apparent: When trying to solve a complex problem, there are no experts but many competing ideas. Therefore, limiting the active participants in refinement activities to a few team members increases the risk of confirmation bias as the diversity of opinion and expertise is artificially limited.
6. Outsiders: Invite stakeholders and subject matter experts to refinement sessions who can contribute to the team’s understanding of the problem and suitable solutions.
7. DoR: A “Definition of Ready” represents either temporary training wheels for a junior Scrum team or an anti-pattern. 
8. Don’t refine too far ahead: Keep the Product Backlog focused on the Product Goal, approximately covering the work of three to six Sprints. This focus will keep the refinement effort minimal as too much refinement is waste: Refine only those Product Backlog items that are likely to be built.
9. User research: Product Backlog refinement and product discovery are closely linked and happen in parallel. User research is part of the refinement activity and includes the Developers, for example, conducting user interviews or building prototypes with production data.
10. INVEST: When refining Product Backlog items, embrace the INVEST principle, popularized by Bill Wake: I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, T – Testable. (Source.)
11. Definition of Done and Acceptance Criteria: A meaningful Product Backlog refinement requires a solid Definition of Done. Moreover, understand the difference between the Definition of Done and acceptance criteria during the refinement. Moreover, achieve a shared understanding of how to apply both.
12. Quality: Consider technical debt and refactoring when refining Product Backlog items as both are continuous efforts of the Developers that can easily absorb 15-30 % of their time.
13. Estimation: Concluding the refinement with an estimation makes sense once you ditch the numbers. Estimating Product Backlog items at the end of the refinement serves one purpose: Understanding whether we are all on the same page about the why, the what, and the how as a team. Or in other words, estimating is about finding closure to move on. Discrepancies during the estimation may point to differences in understanding the Product Backlog item’s nature. Or, they may point to skill gaps among team members that the team should probably address. In any way, these issues increase the risk of not delivering value in the upcoming Sprints. When your Scrum team decides to estimate as part of the refinement process, by all means, stick with relative estimates—story points, t-shirt sizes, or dog races, if you like—and avoid absolute estimates. Those are rooted in the industrial age and Taylorism, related to individual performance, efficiency, remuneration, and hard commitments. Moreover, humans are not good at them either.
14. Not everything is a user story: Don’t fall victim to the user story format fetish: “As a database admin, I want to upgrade the database software to version 5.x, so that….” User stories describe the future system state from a user’s perspective. So, while every user story is a Product Backlog item, not all Product Backlog items are user stories. There are other work items like bugs, spikes, or the non-functional requirement mentioned above. Therefore, avoid wasting everyone’s time by enforcing the utilization of a unified Product Backlog item format during refinement. Moreover, refinement is about the conversation happening between the team members. It is not about picking the correct documentation format.

Conclusion

Product Backlog refinement is a continuous process to create actionable Product Backlogs. This competence of the Scrum team is critical to creating trust with the management and stakeholders as it allows for the regular delivery of valuable Increments. Refinement is a very effective way of risk mitigation in a complex environment.

How are you practicing the Product Backlog refinement? Please share your learnings with us in the comments.