There's a reliable way to judge how a team refines its backlog without attending a single refinement session: sit in on their sprint planning. If planning takes half a day and most of it is spent working out what the stories actually mean, refinement isn't happening. If planning takes twenty minutes because every story was specced out months ago, refinement is happening far too much. Both teams have a problem. They just fail in opposite directions.
The archaeology session
The under-refined team's sprint planning is a three-hour excavation. Someone opens the top story and reads it aloud: "Improve export." That's the whole story. The product owner reconstructs from memory what a stakeholder asked for in a meeting nobody else attended. A developer asks whether it covers the legacy CSV format. Nobody knows. Twenty minutes later the team has written the story that should have existed a week earlier, and there are fourteen more in the queue.
The cost goes well beyond a wasted morning. Estimates produced under that kind of pressure are guesses dressed up as commitments. Dependencies surface mid-sprint instead of mid-refinement, when there was still time to do something about them. And the team starts every sprint already tired of the work, which is a quiet morale tax that compounds.
Waterfall in disguise
The opposite failure looks like diligence, which is why it survives longer. This team has refined everything. Ninety fully groomed stories with acceptance criteria, mockups, and estimates. The next quarter is specced to the pixel.
Then the quarter happens. A competitor ships something, a big customer leaves, the roadmap pivots, and forty of those beautifully refined stories quietly die in the backlog. All that specification effort was inventory waste: work you paid for and never used. Lean manufacturing spotted this pattern decades ago. Software has it worse, because our inventory rots invisibly. Nothing rusts on a shelf. The stories just sit there looking fine while the assumptions underneath them expire.
A fully specced six-month backlog is a waterfall requirements document chopped into tickets. You kept the ceremony names and lost the point. There's a subtler cost too: once a story carries three pages of detail, people hesitate to delete it. Sunk cost drags stale ideas into sprints. The backlog stops being a list of options and becomes a queue of obligations.
The working middle
So how much is enough? Aim for roughly one and a half to two sprints of genuinely ready work at any moment. Ready meaning the team has discussed it, understands it, and could pick it up tomorrow without another meeting.
Why not more? Because readiness decays, and it decays faster than most teams admit. Context evaporates first: the shared understanding built in a good refinement conversation has a shelf life of a few weeks, and after that the ticket text is all that's left, which is never the whole picture. Priorities shift next: the further down the backlog you refine, the higher the odds that item never gets built at all, so every hour spent there is a bet at worsening odds. And estimates go stale: the codebase changes, someone builds a component that makes an eight a three, someone else introduces a migration that makes a three an eight. An estimate from two months ago describes a system that no longer exists.
Why not less? Because you need slack. Product owners get sick. A story turns out to be blocked the day before planning. With a buffer of one and a half to two sprints, a bad week doesn't starve the team; with a buffer of three days, it does.
Does the number flex? Honestly, yes. A team in a volatile startup environment might hold closer to one sprint of ready work because everything past that is fiction. A team in a stable, regulated domain with a fixed annual roadmap can hold more without much waste. The principle stays the same: refine as late as you responsibly can, and no later.
A Definition of Ready that helps instead of gatekeeps
The Definition of Ready has a bad reputation, and it earned it. In plenty of organisations it has swollen into a ten-item compliance checklist: UX sign-off attached, security review logged, architecture diagram linked, three levels of estimate recorded. At that point it isn't a Definition of Ready anymore. It's a stage gate, and stage gates between the PO and the team recreate exactly the handover culture that agile was supposed to remove. The PO throws documents over a wall; the team audits them. Nobody talks.
Keep it small enough to hold in your head. Something like:
- The user value is clear: we can say who wants this and why
- Acceptance criteria exist and the team has actually discussed them
- It's small enough to finish comfortably within one sprint
- There are no known blockers
That's it. Four items, and the operative word in the second one is discussed. A DoR is a prompt for conversation, not a test the PO must pass before being allowed to speak to developers. If a story fails a check, the right response is to talk about it in refinement, not to bounce the ticket back with a rejection stamp.
Who shows up, and how often
Whole team or a subset? It depends on team size, and I'll be honest about that. With five or six people, bring everyone; the shared context is worth more than the hour costs. With ten, a full-team session tends to mean four people talking and six people on their laptops, so a rotating subset (the PO, plus two or three developers who trade off each week) often works better, as long as the rotation is real and the estimates still involve the wider team.
Cadence matters more than attendance. One hour a week beats a monthly three-hour marathon every time. Weekly sessions stay close to the work, so the stories being refined are the ones about to be built. Monthly marathons refine too far ahead by definition, and the last hour of any three-hour meeting produces decisions nobody remembers making. If you're structuring these sessions for the first time, there's a practical walkthrough of the format in our guide to running backlog refinement.
One test tells you whether the session is working: count who talks. If the product owner speaks for fifty minutes out of sixty, that isn't refinement, that's a spec reading with witnesses. Refinement is the team interrogating the work. Questions, objections, "what happens when the payment fails halfway", "didn't we try this in March". The PO brings the what and the why. The team supplies the friction. No friction, no refinement.
Splitting the stories that won't fit
Most refinement conversations eventually hit a story that's too big, and splitting is where teams get stuck. Three patterns cover most cases.
Split by workflow step. A story like "customer completes checkout" contains browse, cart, pay, and confirm. Each step that produces something observable can ship separately. You won't always want to release them separately, but you can build and validate them separately, and that's the point.
Split by acceptance criteria. When a story has seven acceptance criteria, it's frequently three stories wearing a trench coat. Pull the criteria apart and group them by which user need they serve. The grouping usually reveals the natural seams.
Split happy path first. Build the version where everything goes right, then handle failures, edge cases, and weird inputs in follow-up stories. Purists object that the first slice isn't "done done". They're right, and it doesn't matter: a working happy path in the sprint teaches you more than a fully hardened feature that's still theoretical.
Estimation pressure is your best split detector. When the room can't converge on a size (half the team says three, half says thirteen) the story is almost always too big or too vague. Don't average the numbers and move on. The disagreement is the signal. Someone in that room sees complexity someone else doesn't, and finding out which half is right is the actual work.
Estimate in refinement, not on planning day
This one's a hill I'll defend: sizing belongs in refinement. Estimating a story is understanding a story, and understanding is what refinement is for. Teams that defer estimation to sprint planning end up doing refinement during planning, which is how you get the archaeology session from the top of this article.
Planning poker fits refinement well precisely because of that split-detection effect: the silent, simultaneous reveal surfaces disagreement that a "any objections? no? it's a five then" conversation smooths over. It takes a couple of minutes per story once the team has the rhythm. We built a free planning poker room into ScrumMastr for exactly this, and it's the ceremony where the tool earns its keep, especially with remote teams where reading the room is harder.
Do this consistently and sprint planning changes character. Sizing is done. Planning day becomes what it should have been all along: a short conversation about capacity, sequencing, and what the team will commit to. Thirty minutes, sometimes less. The work of understanding happened earlier, a little at a time, when there was room to think.
Start from the top and stop early
If your refinement is currently broken in either direction, the fix starts the same way. Next session, open the backlog at the top. Refine downward, one story at a time, until you have roughly two sprints of work the team genuinely understands. Then stop, even if time remains on the clock. Especially if time remains on the clock.
Everything below that line stays rough on purpose: a title, a sentence of intent, nothing more. It isn't neglect. It's refusing to spend money on decisions you don't need to make yet. The discipline of stopping is harder than the discipline of preparing, and it's worth more.