Anu Smalley

One of the most critical needs in Scrum is to have a well-refined Product Backlog. According to the Scrum Guide, Product Backlog refinement is “the act of adding detail, estimates, and order to items in the Product Backlog.”

There is often confusion as to what should happen during refinement and who should participate. Product Backlog refinement is a continuous activity involving the Product Owner and the Development Team to ensure an output of a set of Product Backlog Items (PBIs) ready for the upcoming Sprint, with the outcome being a common understanding of those PBIs.

An anti-pattern in Scrum is where a Product Owner attempts to refine the backlog without the team. The impact of this type of refinement is that Sprint Planning may get derailed or elongated since the team often needs to repeat refinement activities, or worse, the team starts the Sprint without a good understanding of the work needed, risking a Sprint ending in chaos. Refinement must absolutely be done with the Product Owner and the Development Team with the purpose of developing a common understanding of the PBIs across the entire team.

A simple mnemonic to help with remembering the activities needed is REFINE:

R–Review

Reviewing the Product Backlog is a collective activity resulting in prioritization and ranking. The most important items to the customers and stakeholders must be at the top of the backlog. It is possible to add items in from the Development Team. Based on the current Sprint or the last Sprint Review, the ranking can change.

E–Elaborate

The Product Owner walks the team through each PBI to ensure accuracy and detail. I would often send out in advance the PBIs to be elaborated during the refinement session. During the meeting, we would discuss each PBI in detail and resolve any concerns. On occasion, the team would identify a need for additional research to complete the refinement in the next session.

F–Fix

The Product Owner and Development Team break PBIs into smaller elements to allow completion within a single Sprint. When breaking down user stories, care must be taken to slice vertically, not horizontally. (Check out this great Story Splitting Cheat Sheet.)

I–Investigate

The Development Team may need to do some analysis work for a PBI (such as talk to another team, look into code, or do technical research) to ensure readiness for the next Sprint.

N–Negotiate

The Product Owner and Development Team work together to clarify and adjust acceptance criteria. As a Product Owner, I would read out the story and initial acceptance criteria identified with the stakeholders. After discussion with the Development Team, they were allowed to rewrite the acceptance criteria. This ensured we were all on the same page.

E–Estimate

Upon achieving a common understanding of the PBI, the Development Team can estimate using whichever technique works for them. A common approach is to use the Fibonacci sequence as story point estimates, set through planning poker or affinity sizing as techniques.

Following this simple mnemonic can be a good reminder of what to do, since ignoring any of these activities can lead to an organization suffering long Sprint Planning efforts, failed Sprints, vague or nonexistent Sprint Goals, high rework, and even lead to technical debt.