The value stream

Refining the Product Backlog

A well-ordered Product Backlog is not enough to start a Sprint. The items at the top of the list also need to be clear enough and small enough to be done without unpleasant surprises. Five patterns from A Scrum Book describe this preparatory work, called refinement, and how much of it to do.

Monday morning, in front of a bathroom

The job was indeed at the top of the list, but it was not ready. In Scrum's vocabulary, the list is the Product Backlog, each job is a Product Backlog item (PBI) and each two-week cycle is a Sprint. The Product Owner is the person accountable for the value of the product and the order of the list, and the Developers are the people who do the work. What was missing here is called Product Backlog refinement. Jeff Sutherland, James Coplien and their co-authors devote several patterns to it in A Scrum Book (2019). Each pattern describes a recurring problem and a solution proven by practitioners.

Regular work on the top of the list

The Refined Product Backlog pattern (also called Backlog Refinement Meeting) starts from a tension between two risks. To seize an opportunity at the right time, the team must have understood the need and gathered what it takes to start. But preparing a distant item too early is costly: the time spent is taken from nearer items, and the context will have changed before the team gets there. Dependencies complicate matters, since some items must be delivered before others. Finally, what the team learns each week may change the best order.

The solution is for the Scrum Team, and above all the Product Owner and the Developers, to meet frequently to put the Product Backlog back in order and to split the large items that are coming up. The Developers keep their estimates up to date. Attention goes to the top of the list, to dependencies between items and to external dates: a trading season, a supplier's delivery or the start of the school year. Items planned for the next two or three Sprints should be small enough that none represents more than 10% of a Sprint's work.

To order items according to their dependencies, the authors suggest a technique from engineering, the Design Structure Matrix. You write the items in rows and columns, mark the cells where one depends on another, then reorder until each item comes after those it depends on. If that is impossible, two items depend on each other, and they need to be re-examined or merged.

The pattern gives refinement a second function. Discovering an item several weeks before building it gives the Developers time to think about it. The authors draw on the idea of the "slow hunch" developed by Steven Johnson in Where Good Ideas Come From (2010).

On the time to spend on it, they give a benchmark: the Product Owner should not take up more than 10% of the Developers' working time, and these sessions are scheduled in advance rather than called for as things come up. For a two-week Sprint on a 35-hour week, that comes to 7 hours per person at most, for example two weekly sessions of an hour and a half, or 6 hours per Sprint.

The Definition of Ready

The Definition of Ready pattern (nicknamed Ready-Ready) addresses the bathroom problem. When the Developers misunderstand an item, the effort swells along the way and the Sprint misses its goal. Several forces nevertheless push teams to start too early. An idea is born abstract, whereas building it requires something concrete. In a planning meeting, the group is tempted to put off the hard questions in order to make progress. The Product Owner thinks in terms of needs and markets, the Developers in terms of design, and there has to be a clear point of contact between these two worlds.

The solution is a short list of criteria that every item must meet before it can be a candidate for a Sprint. The pattern proposes six:

A Product Backlog is said to be "Ready" when it has enough compliant items at the top to fill a Sprint. The authors advise adding a criterion on external dependencies, because an item that is waiting for something outside the team's control puts the whole Sprint at risk. For Mrs. Lefèvre's job, the list would become: quote signed, materials chosen and ordered with a delivery date, technical survey done, duration estimated by the tradespeople, and acceptance criteria agreed with the customer.

The pattern specifies that only the items near the top of the list need to be ready, and that the aim is for them to cross this threshold without stopping at it. If an item is not ready, it is first up to the Product Owner to rework the analysis. The authors recall a tradition told by Jeff Sutherland in Scrum: The Art of Doing Twice the Work in Half the Time (2014): faced with a backlog that is not ready, the Developers would have the right to go to the beach. They temper it straight away by asking the Developers how they can help the Product Owner. According to them, the first formal description of this practice seems to be due to Richard Kronfält, in 2008.

Enabling Specification: enough information to move ahead without asking again

The Enabling Specification pattern tackles a habit that arose with agile methods: throwing an idea into the Product Backlog in the belief that the details will come later. Scrum accepts that requirements emerge along the way, and one may be tempted to conclude that they will all reveal themselves during development. The authors object that building something in order to discover a requirement is a heavy-handed way of doing it, when a conversation with a user would have been enough. Most schedule slippages, in their view, come from insufficient or poorly communicated analysis.

The solution is for the Product Owner to provide, for each upcoming item, a specification rich enough that a person competent in the field could build a solution without asking for significant clarification outside the Scrum Team. The expression comes from patent law, where a patent is only valid if it allows a person skilled in the art to reproduce the invention without consulting the inventor. The Developers keep the last word: if they judge that they do not know enough, they do not take the item into the Sprint.

The authors stress that the specification counts less for what is written down than for what the team has understood. It is built through conversations, examples and mock-ups, and the document serves mainly as a reminder. A good specification includes written test criteria.

Small at the top, large at the bottom

Small Items

The Small Items pattern starts from an observation: big ideas are easy to have, but large items are hard to understand, to estimate and to finish. A 20% error on twenty days of work amounts to four days, whereas on two days of work it amounts to less than half a day. A large item may not be finished by the end of the Sprint, and the team then has nothing to show and no feedback to gather. When each task lasts several days, the Daily Scrum, the team's daily check-in, no longer tells anyone anything.

The solution is to break the work down into items that the Developers understand well and finish quickly. For tasks in the Sprint's work plan, the authors recommend two days at most. They make clear that the primary aim is understanding and that the accuracy of forecasts comes second: splitting forces you to design, and it is by designing that you understand. In return, the team spends more time refining and handles more items.

Granularity Gradient

Splitting everything finely would be wasteful, and that is the problem of the Granularity Gradient pattern. Splitting takes work, and the more distant an item is, the more likely it is to change or disappear. The authors cite Barry Boehm (Software Engineering Economics, 1981), according to whom an estimate can be wrong by a factor of up to four as long as the requirements are not detailed. They point out a second risk: very fine-grained estimates give anyone who wants it a way of monitoring the Developers hour by hour.

The solution is to match the size of items to their depth in the list. For the next two or three Sprints, no item should exceed 10% of a Sprint's work, and 5% is preferable. Beyond four or five Sprints, an item can be of any size and express little more than an intention. All of them remain estimated, but the distant estimates are refreshed less often.

What the 2020 Scrum Guide says

The patterns go further than the Scrum Guide, and several of their benchmarks do not appear in it.

Limits and pitfalls

The most common pitfall is turning the Definition of Ready into a barrier. The Developers then refuse any item that does not check every box, the Product Owner writes ever thicker documents to cover themselves, and you are back to the sequence of separate phases that Scrum set out to avoid. The pattern guards against this risk by asking for a short list and a passage without stopping, but the beach story lends itself to a confrontational reading.

Over-refinement is another failing. Items detailed months in advance form a stock of decisions that grow stale. The opposite failing shows up at Sprint Planning, which turns into a long discovery session because nobody looked at the items beforehand.

Splitting itself can go wrong. Splitting by trade or by technical layer (all the plumbing, then all the tiling) produces pieces none of which has value on its own. A small item must remain a deliverable that someone can use or check.

Finally, the thresholds cited here (10%, two days, two to three Sprints) are benchmarks drawn from the authors' experience, and Boehm's work concerns software. None has been validated by comparative trials. The article Criticism and the state of the evidence sets out what is known and what is not.

Further reading

Main sources: J. Sutherland, J. O. Coplien et al., A Scrum Book: The Spirit of the Game (2019), patterns Refined Product Backlog, Definition of Ready, Enabling Specification, Granularity Gradient and Small Items; K. Schwaber and J. Sutherland, The Scrum Guide (2020); J. Sutherland and J. J. Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (2014); B. Boehm, Software Engineering Economics (1981).