There's a story in your backlog right now that has survived three refinement sessions without a number on it. Everyone recognizes it when it comes up. Someone asks a clarifying question, the product owner answers, someone else asks a different question, twenty minutes evaporate, and the story slides back into the pile with a shrug and a "let's revisit next time."
The usual diagnosis is that the team needs to get better at estimating. That diagnosis is almost always wrong. A team that sizes most stories in ninety seconds didn't suddenly forget how estimation works when it hit this one. The story is broken. Estimation is a stress test for story quality, and this story keeps failing it.
That reframe changes what you do about it. You stop scheduling estimation training and start looking at what you're feeding the team.
What a sizeable story actually needs
Four things, and none of them is "lots of detail."
A clear user outcome: who is this for, and what changes for them when it ships. A boundary: at least one explicit statement of what's not included, because the edges of a story are where estimates go to die. Acceptance criteria the team helped shape, not criteria handed down from above. And named dependencies: the other team, the pending API, the design that doesn't exist yet.
Notice what's not on the list: certainty. You can size uncertainty. Points bundle effort, complexity, and the stuff you don't know yet into one number, which I've argued elsewhere in what story points actually measure. A story with a known unknown ("we've never touched the billing provider's webhook API") is perfectly estimable. It's just bigger. What you can't size is a story where five people hold five different pictures of what it even is. That's not uncertainty about the work. That's disagreement about the request, and no card in the deck represents "we're not talking about the same thing."
If you want a mnemonic for the healthy version, INVEST is fine: independent, negotiable, valuable, estimable, small, testable. Note that "estimable" is one of the six letters. The people who coined the acronym understood that sizeability is a property of the story, not a skill of the estimator. But don't turn it into a compliance checklist. The reflex matters more than the letters.
The template, treated honestly
"As a user, I want X, so that Y." You know it. Your tooling probably has it pre-filled in the description field.
For a team new to writing stories, it's a genuinely useful scaffold. It forces two questions that beginners skip: who is this for, and why do they care. Plenty of vague requests fall apart the moment someone tries to fill in the "so that" clause and discovers there's nothing true to put there. That's the template doing its job.
The trouble starts when it becomes liturgy. "As a developer, I want to upgrade the Postgres driver, so that the Postgres driver is upgraded." Grammatically complete, informationally empty. Every backlog that mandates the template contains dozens of these, and they're worse than plain task descriptions because they wear the costume of user value while carrying none. If a story is honest infrastructure work, say so in plain language and justify it on its own terms.
The test is simple. Cover the template and ask: does the story still name a person and a change in their world? If yes, the format was never the point. If no, no amount of "as a user" will save it.
Four stories that stall every refinement
Some stories fail the stress test in recognizable ways. You've met all of these.
The disguised task list. "Implement the /export API endpoint." This is a slice of a solution, not a story. There's no user in it, no way to tell when it's done from the outside, and the moment you ask the team to size it, the discussion turns into an architecture debate because the architecture is the only content the story has. It also travels in packs: three tickets later you'll find "build the export UI" and "wire up the export button," and none of the three delivers anything a user can touch. Recombine them around the outcome ("a member can download their project as CSV") and suddenly there's something to size.
The epic in a trench coat. "Users can manage their notification preferences." One tidy sentence, fifteen stories inside it. Email, push, per-project overrides, digest frequency, unsubscribe compliance, the settings UI, the migration for existing users. The telltale symptom is a wild vote spread: 3, 5, 13, 20, because each person silently picked a different slice to imagine. When the spread looks like that, don't average it. Ask each voter what they thought was included, write the answers down, and you've done the splitting work already.
The vague wish. "Improve dashboard performance." Improve by how much, measured where, for whom, on what connection? A story you can't finish is a story you can't size, and this one has no finish line. The fix is to force a threshold into it: "dashboard loads in under two seconds for projects with up to 5,000 tasks." Now it's checkable, which means it's arguable, which means it's estimable.
The solution masquerading as a need. "Add a Redis cache to the search service." Maybe that's the right call. But the story has skipped the part where we learn what hurts. If the underlying need is "search results feel slow on large projects," there might be a cheaper fix, and the team can't propose it because the story already decided. Solutions in the title also make estimates weirdly brittle: you're sizing one implementation rather than one outcome, and the first surprise invalidates the number.
Acceptance criteria are claims about scope
Here's a way to think about acceptance criteria that makes their effect on estimation obvious: each criterion is a checkable claim about what's inside the story. "Export includes archived items." True or false, in or out. Someone on the team can read it and say "that doubles the work, the archive lives in cold storage," and now you know something that would otherwise have surfaced mid-sprint as a blown estimate.
This is why criteria written collaboratively during refinement beat criteria delivered fully formed. It's not a process nicety. The act of writing them is where hidden scope surfaces, because every claim invites a developer to dispute it while disputing is still cheap. A product owner writing criteria alone can only encode what they already know. The team's questions encode what nobody knew. If your refinement sessions don't leave room for that back and forth, that's a cadence problem, and I've written about finding the right dose in backlog refinement: how much is enough.
A rough rule that has served me well: a story with zero criteria isn't ready to size, and a story with twelve is probably an epic in a trench coat. Three to six checkable claims covers most well-cut stories.
Ask what would make this a 13
When votes converge a little too quickly on a comfortable 5, try this before moving on: "what would make this a 13 instead of a 5?"
The answers come fast, and they're always the assumptions. "Well, if it has to work on mobile too." "If we're migrating existing data rather than just handling new records." "If permissions apply per project instead of globally." Every answer is a piece of scope that someone quietly assumed was excluded. Sometimes everyone assumed the same exclusions and the 5 stands. Often they didn't, and you've just found the disagreement while it costs ten minutes instead of a sprint. Either way, write the exclusions into the story. An assumption on the ticket is a decision; an assumption in someone's head is a bug report waiting to be filed.
The question works in reverse too. "What would make this a 2?" is the fastest path to finding the thin slice worth shipping first.
An honest planning poker round does a blunt version of this for free, which is most of why the format exists: independent votes revealed together turn silent assumptions into a visible spread you have to talk about. We built planning poker into ScrumMastr because the reveal is the valuable part, but the tool only surfaces the gap. The "what makes it a 13" question is how you close it.
A rewrite, start to finish
Take a story I'd bet money you've seen some version of:
"As a user, I want better search so that I can find things faster."
Template? Present. Estimable? Not remotely. "Better" has no finish line, "user" could be anyone, and "find things" spans everything from typo tolerance to full-text indexing of attachments. This story is a vague wish wearing the template as camouflage. Ask a team to size it and you'll get numbers, because people are polite, but the numbers will mean nothing.
Now the rewrite, after one refinement conversation that asked who's actually complaining and about what:
"A project member filtering a task list with more than one page of results can combine assignee and status filters to narrow it."
With criteria the team shaped together:
- Assignee and status filters apply together, not as two separate views
- Filter state is encoded in the URL and survives reload and sharing
- Archived tasks stay excluded unless the status filter explicitly includes them
- Global search is untouched; that's a separate story if it's a story at all
- Uses the existing task query API; no new backend endpoints
Same underlying complaint. But this version is sizeable, and not because it's small. It's sizeable because every line is a claim someone can check, the fourth line draws the boundary, and the fifth names the dependency situation. Votes on this will land in a tight band, maybe 3s and 5s with a lone 8 from whoever has fought the URL-state code before. That 8 is a conversation worth having. The original story couldn't even produce a useful disagreement.
Refine the story, not the estimate
So, practical advice for the next time a story stalls in refinement for the second time: stop trying to size it. The room already gave its verdict, and repeating the vote won't change it. Rewrite the story right there while the confusion is fresh. Split it along the seams the discussion exposed, add the boundary everyone was assuming differently, or send it back with the one specific question that kept looping, attached and named.
It feels slower than pushing a number through. It isn't. A story the team can't estimate is a story the team can't build without surprises, and refinement is the cheapest place you will ever discover that. The estimate was never the problem. It was the messenger.