Backlog Refinement: What It Is and Why It Matters
Refinement is the least visible of the recurring activities and the first thing dropped in a busy quarter, because nothing about it produces anything. It is the work of getting the next few items ready to be worked on, and a team that stops doing it discovers the cost about three weeks later, in a planning session that runs to two hours and settles very little.
What ready actually means
Four properties make an item ready, and the list is worth agreeing explicitly, because a team that has never written it down will each be working to a different one.
It is understood. Somebody can describe what the thing is for and what it has to do, in enough detail that building it will not throw up a surprise in the first hour.
It is small enough. It can be finished inside a cycle, which usually means one to three days of work. Items that cannot are not ready; they are two items that nobody has separated yet.
Its acceptance is clear. What has to be true before anybody calls it done, which is a different thing from what it has to do, and the difference has a treatment of its own.
Its dependencies are known. What it needs from outside the team, whether that thing exists, and whether anybody has asked for it. This is the property most often skipped and the one behind the most expensive failure, because a dependency discovered mid-cycle stops the work and there is rarely anything to swap in.
What happens in the session
Section 5 of the PMBOK® Guide Eighth Edition gathers the techniques a team uses for this kind of work, and refinement is mostly three activities, none of them a status update.
Splitting. Anything too big to finish in a cycle gets broken into pieces that each deliver something. This is the hardest of the three and the most valuable, because a good split produces two items that can each be finished, and a bad split produces two items where one is useless without the other.
Answering. Every question that would otherwise be asked mid-cycle gets asked now, while asking is cheap and nobody is waiting. The product owner is in the room precisely for this, and a refinement session without them is an estimating meeting.
Removing. This is the activity nobody expects and the one that keeps a backlog usable. Items stop mattering. The thing they were for was cancelled, the workaround became permanent, the person who asked for it has gone. A backlog that only ever grows has had no refinement in it, whatever the calendar says.
The cheapest place to find a problem
The economics are the reason to protect the slot. A question answered in refinement costs ten minutes of two people's time. The same question answered mid-cycle costs a day of somebody's cycle, a handover, and usually a conversation with whoever was expecting the item. A dependency found in refinement is a phone call. The same dependency found on a Tuesday is a stopped piece of work and an item coming out of the cycle.
A utilities network operator was rolling out field mobility to about four hundred engineers, delivered by a team of nine. Refinement had been a standing forty-five minutes twice a week, and in a busy quarter it went, because it was the only thing in the calendar producing nothing.
The symptoms arrived over the next two months. Planning sessions stretched to two hours, with perhaps half the items unestimable because nobody could say what they involved. Two items were started and abandoned mid-cycle after a dependency on the asset management system surfaced, which cost about six days between them. And the backlog had grown from around sixty items to a hundred and forty, with nothing removed from it in four months.
Reinstating the slot took one conversation. The first three sessions removed thirty-one items outright, every one of them something nobody was ever going to do, split nine that were too large, and found the asset system dependency sitting under the next three items in the same family as the two that had failed. Planning came back to forty minutes.
For a PMP® candidate, the useful reading is that refinement is preparation work with an economic case behind it, so chaotic planning or work abandoned mid-cycle is usually describing its absence. A response that adds a control to the cycle is treating the symptom, because the cause sits upstream of it. Ask whether the work was ready before asking why it went wrong. Practising where the failure is visible in execution and was caused in preparation takes repetition, which a structured PMP exam preparation course is organised to give.
Two numbers say whether refinement is working. How many items in the last planning session could not be estimated, and how many items came out of the backlog in the last month. If the first is more than a couple and the second is zero, the slot either does not exist or has quietly become something else.
Interested in going further?
Refinement produces nothing, which is why it goes first and why its absence shows up somewhere else entirely. Omega's PMP® Exam Preparation works through situations where the visible failure and its cause sit in different weeks.
The techniques behind preparing and ordering work are set out in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A191: Product Backlog vs Sprint Backlog
A106: Product Backlog vs Project Scope
A148: Which Conflict Resolution Technique Should You Use?
A180: Facilitation Techniques for Difficult Project Conversations
A189: Definition of Done vs Acceptance Criteria
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
