Backlog refinement: how much is enough, and what is Ready

Two failures sit either side of good refinement. In the first, Sprint Planning opens with a story nobody has read, and the first forty minutes are spent finding out what it means. In the second, the Product Owner has written detailed specifications for the next eight months, and half of them are wrong by March. The art is in the middle: refine what is about to be needed, and leave the rest rough.

What each source says

The Scrum Guide's definition is short. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller, more precise items. It is an ongoing activity to add details such as a description, an order and a size, and the attributes often vary with the domain of work. Items that can be Done within one Sprint are deemed ready for selection at Sprint Planning, and they usually acquire that clarity through refinement. The Guide prescribes no meeting, and lists refinement among the things done during the Sprint as needed. The Developers are responsible for sizing, and the Product Owner may influence them by helping them understand and choose trade-offs.

The SBOK® Guide's Refine Prioritized Product Backlog process (called "grooming" in earlier editions) adds more structure. The Product Owner continuously updates and maintains the backlog, working with stakeholders to capture changes in their needs, and refines epics and stories so those intended for the next Sprint are ready for commitment. It describes a Prioritized Product Backlog Review Meeting as a tool, and a Definition of Ready as the test a story must pass.

How much is enough

The SBOK is specific. It says one of the Product Owner's key responsibilities is making sure the requirements to be included in the next two to three Sprints are refined into suitable user stories, and recommends spending a significant amount of time in each Sprint on refining. The Scrum Guide gives no figure.

Take the SBOK's figure as a starting point and adjust it. If your Sprints are short and your priorities change often, two Sprints of refined work is plenty. If your work has long lead times, such as waiting for design or legal review, you will need to look further ahead for the items that need it.

A simple check is at the end of each Sprint Planning. Did we choose from clear items? Was there a story we could not plan because we did not understand it? If so, refine more. Did we refine items that moved down or disappeared? If so, refine less.

What a session does

The SBOK says the intent of a review meeting is to make sure of four things: stories and their acceptance criteria are understood and properly written; everyone on the team understands them; the high-priority stories are refined well enough for the team to estimate and commit; and irrelevant stories are removed and approved changes or risks are incorporated.

The SBOK adds practical advice about running one. The Product Owner takes the lead and should set objectives, ideally with an agenda, because without objectives the session is unstructured. Invite only the stakeholders whose feedback is required, because too many participants lower efficiency. Include all the team members, because their input is valuable. If the session changes the order, the team should agree with the change.

An illustration of a thirty-minute session, ours and not either source's:

1. Look at the top of the backlog and the Sprint Goal for the next Sprint.
2. Pick the next two or three items that are not yet clear.
3. For each, ask: what does done look like, what are we unsure of, can we finish it in a Sprint?
4. Split anything too big, and size what is ready.
5. Note questions for the Product Owner to answer before planning.
6. Remove or defer one item that no longer earns its place.

Other ways refinement happens

Neither source limits refinement to a meeting. The SBOK says refining should happen throughout the project: the Product Owner writes new stories or reorders existing ones, and stakeholders or team members suggest new items. The Guide treats it as an activity, not an event. In many teams a lot happens in short conversations: a Developer asks a question about a story, the Product Owner answers, and the story improves.

Several inputs feed it. The SBOK lists rejected stories, which simply stay in the backlog unmarked as done so that they can be reordered and considered again, approved change requests, identified risks, dependencies and the lessons from the last retrospective. In other words, the backlog is where everything learned in the Sprint is turned into the next plan.

A Definition of Ready: use with care

The SBOK describes a Definition of Ready as a set of criteria a story must meet before it is estimated and included in a Sprint, for example: written in enough detail to estimate, with clear acceptance criteria, any related documents attached and small enough to complete in one Sprint. It puts the onus on the Product Owner to define requirements properly, and says the team commits only to stories that meet it.

The Scrum Guide has no such thing. Its equivalent is the plain observation that items which can be Done within a Sprint are ready for selection.

A Definition of Ready can help a team that keeps being handed unclear work. It gives everyone a reason to say "not yet". The risk is that it turns into a gate. If stories are refused for lack of a field and not for lack of understanding, it creates paperwork. Two guards help. Keep it short, perhaps four or five lines. And treat it as a conversation starter, not a checkpoint. A story that the team understands well enough to do is ready, whatever the checklist says.

Common mistakes

• Refining everything. Far-off items change. Spend the time near the top.
• Refining nothing until planning. The first forty minutes then go on reading.
• Treating refinement as a meeting only. Much of it is conversation as questions arise.
• A Product Owner who refines alone. The Developers will find gaps the Product Owner cannot see, and they do the sizing.
• A crowd. The SBOK warns that too many participants reduce efficiency.
• Never deleting. A backlog that only grows is not refined. Removing items is refinement too.
• Gating on the checklist. Judgement beats form.

The Agile Manifesto principle that simplicity, the art of maximising the amount of work not done, is essential applies to refinement as much as to code.

How to practise it

In the simulator, the backlog is refined in the middle of a Sprint. A change request arrives, the current Sprint stays as committed, and you decide where the request belongs in the ordered backlog.