There is no Backlog Refinement event in the Scrum Guide. There never has been. The 2020 edition mentions it once, in passing, as an ongoing activity that may consume up to 10% of the team’s capacity. It does not prescribe a format, a frequency, a duration, or a facilitation approach. It simply notes that the Product Backlog needs to be refined – and leaves the rest to the team.
This absence of prescription has produced an extraordinary variety of practices, most of which share a common problem: they focus on the activity rather than the outcome. Teams run refinement sessions. They estimate stories. They split epics. They ask questions and add acceptance criteria. And then they arrive at Sprint Planning unprepared, the session runs long, and everyone wonders why planning is always painful.
The purpose of refinement is not to do refinement. The purpose is to make Sprint Planning fast, decisive, and grounded in shared understanding. Every refinement activity should be evaluated against that purpose.
The Hook: The Four-Hour Sprint Planning That Should Have Taken Ninety Minutes
The pattern is recognisable. Sprint Planning is scheduled for two hours. The first story is presented. The team asks questions that should have been asked weeks ago. The Product Owner is unsure about some of the acceptance criteria. Someone raises a dependency that nobody had mapped. The estimation discussion reveals that two team members have completely different understandings of what the story requires.
This happens with the second story. And the third. By ninety minutes in, the team has planned one sprint-worth of stories and is exhausted from the cognitive load of understanding things that should have been understood in advance.
Four hours later, the sprint is planned. Everyone is tired. The commitment feels fragile because half the stories were not really understood when they were accepted. And next sprint, it happens again.
This is not a Sprint Planning problem. It is a refinement problem. Specifically, it is the consequence of refinement that treated the activity as complete when the stories were estimated, rather than when the team was genuinely ready to plan them.
The Reality: What Refinement Gets Wrong
Refinement as Estimation Theatre
The most common dysfunction: refinement sessions that are structurally identical to planning poker sessions. Stories are presented. The team asks a few questions. Points are assigned. The story is marked as refined. The session moves on.
The problem is that estimation and understanding are not the same thing. A team can estimate a story it does not understand – it just estimates with low confidence and high variance. The number produced in a planning poker session is a measure of perceived complexity, not of genuine readiness. And a story that has been estimated but not understood will create problems in planning and in the sprint.
The test for genuine readiness is not “does this story have an estimate?” It is: “Can any team member describe, in two sentences, what done looks like for this story – without referencing the ticket?”
If the answer is no, the story has not been refined. It has been estimated.
Refinement as a Single Weekly Meeting
The second dysfunction is treating refinement as a ceremony with a fixed time slot. Tuesday at 3pm, sixty minutes, the same group of people every week. This structure creates several problems.
First, it batches refinement into a single point in time, which means stories that need significant clarification get the same amount of time as stories that need almost none. The meeting format cannot distinguish between them.
Second, it creates a queue. Stories that are not ready by Tuesday do not get refined until next Tuesday. If a story needs input from a stakeholder who is unavailable that week, it waits. Sprint Planning happens regardless.
Third, it creates a false sense of completion. Stories that passed through the Tuesday session feel refined even if the fundamental questions were not answered. They have been through the ceremony. The ceremony validates them, regardless of whether the outcome was achieved.
Good refinement is continuous, not ceremonial. It happens in conversations between the Product Owner and individual team members. It happens in quick exchanges after the Daily. It happens asynchronously in comments on tickets. The Tuesday session, if it exists, is one node in a continuous process – not the process itself.
Refinement Without the Right People
The third dysfunction is refining stories without the people who need to be involved. The classic example: a refinement session where the Product Owner presents business requirements to developers who have no context for the underlying customer problem. The team estimates based on technical complexity. The “why” is missing. The stories are technically scoped but strategically orphaned.
Good refinement requires whoever has the relevant knowledge for the stories being discussed. For a story with significant UX implications: someone who has seen the user research. For a story with complex integration requirements: the engineer who owns the relevant system. For a story that depends on a legal decision not yet made: clarity that the decision exists or a plan for when it will be made.
The right people are not always available at a fixed Tuesday slot. This is another reason why ceremonial refinement is structurally limited.
“A refined story is not one that has been through the refinement meeting. It is one where every person who will work on it could describe the expected outcome, the relevant constraints, and the definition of done – before the sprint starts.” Markus – agile-checksum.com
The Checksum: What Ready Actually Means
The Scrum Guide describes a concept called the Definition of Ready – an optional, team-defined checklist that a story must meet before it can be selected for a Sprint. Not all teams use it, and it can become bureaucratic if applied too rigidly. But as a thinking framework for what refinement is trying to achieve, it is useful.
Here is what a genuine Definition of Ready should capture:
1. The outcome is described in user terms, not implementation terms.
“As a user, I want to filter search results by date” is a user story. “Implement date filter on search endpoint with ISO 8601 parameter” is a technical specification. The latter may be the right level of detail for implementation, but refinement should start from the former – because the user terms carry the context that determines whether the implementation is correct.
2. The acceptance criteria are specific and testable.
Not “the filter works correctly” but “when a date range is applied, only results within that range are returned; results outside the range do not appear; an empty state is shown when no results match the filter; the filter persists through pagination.” Each criterion should be falsifiable – it should be possible to write a test that either passes or fails against it.
3. Dependencies are identified and either resolved or explicitly managed.
A story with an unresolved dependency is not ready. It may be estimable, but it is not plannable. Dependencies should be listed, status should be known, and either the dependency is resolved before planning or there is an explicit plan for how it will be managed within the sprint.
4. The team has had a technical conversation, not just a business conversation.
The Product Owner describes the what. The engineers need to have discussed the how – at least at a high level – before the sprint. Not to produce a detailed technical design, but to identify the unknowns: the parts of the implementation that require investigation, the components that will need to change, the risks that need to be flagged. A story that has only had a business-level conversation in refinement will require a technical conversation in planning. That is planning time spent on refinement work.
5. The size is understood well enough to make a commitment.
This does not require story points. It requires that the team has enough understanding of the story’s scope to make a reasonable commitment to completing it within a sprint. If the answer to “can we complete this in one sprint?” is “we genuinely don’t know,” the story needs more refinement – or it needs to be split.
Real-World Examples
The Team That Split Everything Into One-Point Stories
A development team in a fintech company had taken a particular approach to refinement: every story was split until it fit into a one-point estimate. The logic was that small, well-defined stories are easier to complete and deliver. This is true. But in practice, the splitting was being done without adequate understanding – stories were split into smaller units of the same uncertainty.
The result was a backlog full of tiny stories that each looked simple but collectively formed a system nobody had mapped. In Sprint Planning, the team would select ten one-point stories, plan them individually, and then discover mid-sprint that stories 4, 7, and 9 could not be completed independently because of integration dependencies nobody had surfaced in refinement.
The fix was not to stop splitting stories. It was to require that the dependencies between split stories were explicitly mapped before any of them entered planning. If the team could not describe the integration sequence, the split was premature.
The Product Owner Who Refined Everything Alone
A common anti-pattern: the Product Owner refines stories on their own, writing detailed acceptance criteria, splitting epics, adding technical notes – and then presents the refined stories to the team in planning. The stories are well-written. The acceptance criteria are clear. And the team has no ownership of them, because they were not part of forming the understanding.
Refinement that happens in isolation produces stories that are externally coherent but internally opaque – the team can read what is required, but they have not internalised the reasoning, the context, or the constraints. Questions arise in the sprint that should have been answered before it. The team defers to the Product Owner on decisions they should be empowered to make themselves.
Good refinement builds shared understanding. It cannot be done by one person and then handed to another. The process of questioning, challenging, clarifying, and occasionally pushing back is not overhead – it is the mechanism by which shared understanding is created.
The Takeaway: Refinement Is a Quality Gate, Not a Meeting
The test of your refinement practice is not how many stories went through it. It is how Sprint Planning feels.
If Sprint Planning regularly runs long, requires significant clarification, produces fragile commitments, or ends with the team unsure about what they have agreed to – your refinement is not working. Not because you are running the wrong format or using the wrong estimation technique, but because the stories arriving in planning are not genuinely ready.
The fix is not to add more refinement meetings. It is to change the definition of done for refinement itself. A story is not refined when it has been discussed. It is refined when every person who will work on it can describe the expected outcome without reading the ticket.
Run the checksum on your refinement practice:
- In your last Sprint Planning, how many stories required significant clarification that should have been done in advance? If more than one: your refinement output is not ready enough.
- Can any team member, right now, describe the acceptance criteria for the top five backlog items in their own words? If not: the understanding is thinner than the documentation suggests.
- When a story has an unresolved dependency, what is the standard practice? If the answer is “we plan it anyway and resolve the dependency in the sprint”: that is not a planning problem, it is a refinement problem being paid for in sprint execution.
Glossary Terms Used in This Article
- Product Backlog – An ordered list of everything that might be needed in the product, owned and managed by the Product Owner.
- Product Owner – The Scrum accountability responsible for maximising the value of the product and managing the Product Backlog.
- Sprint Planning – A Scrum event in which the team plans the work to be performed in the upcoming Sprint.
- Sprint – A fixed time-box of 1–4 weeks in which a Scrum team delivers a potentially releasable increment.
- Definition of Done – The shared agreement on what “complete” means for a product increment.
- Scrum Master – The Scrum accountability responsible for establishing Scrum and serving the team and organisation.
No Fluff. Just Real Agile.
Straight to your inbox. No buzz, no spam.
Related Articles
"Agile Waterfall: The Language of Agile Without the Authority to Be Agile"
Many organisations have adopted Agile vocabulary completely and Agile decision-making authority not at all. The result is not a hybrid. It is Waterfall with better-named phases and a higher meeting frequency.
Read Article →"Retrospectives That Generate Insight but Not Change"
Teams that run retrospectives diligently and change nothing are not failing at retrospectives. They are succeeding at a different activity entirely – one that looks like continuous improvement but produces none.
Read Article →"Scrum Theatre: Why the Daily Becomes a Status Meeting"
The Daily Scrum is the most observed ceremony in Agile. It is also one of the most consistently misused. Here is why it degrades into a status report – and what the structure actually requires.
Read Article →