Product Backlog Refinement

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity 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 and refinement is a key activity that enables this.

The Scrum Team decide how and when refinement is carried out. It is typical for some time to be spent on refinement in every Sprint.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones.

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 in the future, 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 to 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, product and how they work together.

Scrum Teams often aim to have enough refined work on the Product Backlog to allow for some contingency. If a Product Owner was absent for a time, the Developers would not be blocked by a lack of refined and ready Product Backlog items.
Tips

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 in the interests of increased collaboration and transparency.
  • Many Scrum Teams create a workflow which ensures each Product Backlog items benefits from a combination of these approaches.

The Scrum Team should use Scrum to inspect & 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 is unable to successfully refine a Product Backlog item due to insufficient knowledge, some work may be required to learn more about the PBI. This work is often called a Spike.

A Spike is a good practice learning activity designed to deepen our understanding of a PBI. The Spike may be added to the Product Backlog and work completed against it to increase the Scrum Teams 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 PBI’s will be needed to ensure they are small enough that they can be Done in a Sprint. For new Scrum Teams, this will be a critical skill to learn 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 they are being actively worked on by Developers.