Product Backlog Refinement
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. This activity is ongoing to add details such as a description, order, and size. Attributes often vary with the domain of work.
This is an ongoing process in which the Scrum Team collaborate. The Product Owner is accountable for effective Product Backlog management; refinement is a critical activity enabling this. The Scrum Team decides how and when refinement is carried out. It is typical for some time to be spent on refinement in every Sprint.
If Product Backlog items are sized as part of refinement, then this will be the responsibility of the Developers. The Product Owner may influence the Developers by helping them understand and select trade-offs.
Refining Product Backlog items to the right level at the right time is important. In a complex environment, it is difficult to predict what will be needed or how needs may change as more becomes known about the product. Refining too early could be a waste of time and effort. Refining too late or not refining at all could reduce the quality of the Sprint Planning event and limit the ability of the Developers to produce a Done Increment by the end of a Sprint.
The amount of effort required to refine a Product Backlog can vary widely and is not set by Scrum. In early Sprints, this effort may be higher as the Scrum Team works to detail the work required to build the product at a low level of detail. In later Sprints, less time may be needed as the Scrum Team understands more about the domain and the product and how they work together, and the volume of new work entering the Product Backlog may be reduced.
Higher-ordered Product Backlog items are usually more precise and detailed than lower-ordered ones. Scrum Teams often aim to have enough refined work on the Product Backlog to allow for some contingency. If a Product Owner is absent, the Developers will not be blocked by a lack of refined and ready Product Backlog items.
It is up to the Scrum Team to choose the good practices to help them refine the Product Backlog. It is common for Product Backlog refinement to occur in different ways. For example:
- Developers may do it individually or in small groups with or without the Product Owner.
- The Scrum Team may meet each Sprint to carry out some Product Backlog refinement together to increase collaboration and transparency.
- Many Scrum Teams create a workflow which ensures each Product Backlog item benefits from a combination of these approaches.
The Scrum Team should use Scrum to inspect and adapt to find the best combination of practices to enable them to maintain a suitably refined Product Backlog without introducing too much waste. The practices to achieve this will emerge over time.
If a Scrum Team cannot refine a Product Backlog Item due to insufficient knowledge successfully, some work may be required to learn more about the Item. This work is often called a spike. A spike is a good practice learning activity designed to deepen our understanding of a Product Backlog Item. The spike may be added to the Product Backlog and work completed against it to increase the Scrum Team’s understanding of work before full work occurs in a later Sprint. A spike should have clear objectives and expected outcomes. It is a good practice to timebox spikes as research and learning can be unlimited, and good enough results can be achieved by increasing understanding without seeking perfection.
Decomposing or splitting Product Backlog items will be needed to ensure they are small enough to be Done in a Sprint. This will be a critical skill for new Scrum Teams, and it may take some time for them to learn how to do this effectively.
Product Backlog items may be further refined in Sprint Planning and during the Sprint when Developers are actively working on them.