Backlog Work
A user story is only estimable when the team understands what done looks like. Good estimation starts with clear stories, uses relative comparison instead of guesswork, and treats a hard-to-estimate story as a signal to clarify or split rather than to argue.
If the team cannot agree on an estimate, the usual cause is an unclear story, not a lack of skill. Acceptance criteria, a clear user, and a defined outcome make effort far easier to judge.
A quick test: can someone restate what the story delivers and how you would verify it? If not, the story needs refinement before any number is worth casting.
Rather than inventing a number from scratch, compare the story to ones the team has already finished. Is this bigger or smaller than that three-point story everyone remembers? Relative judgment is faster and more consistent than absolute guessing.
Vote privately, reveal together, and discuss the spread. The conversation after the reveal is where hidden complexity, dependencies, and assumptions come to light.
When a story keeps landing on a large card, splitting it usually helps more than debating it. Slice by workflow step, by user type, by happy path versus edge cases, or by data source.
Smaller stories estimate more accurately, move across the board faster, and give the team more frequent signals of progress. A backlog of small, clear stories is easier to plan than a few large, vague ones.
Small enough to finish comfortably within a sprint, ideally within a few days, so it flows rather than lingering across sprint boundaries.
The delivery team that will build them. Estimates from people not doing the work tend to miss real complexity.
Persistent disagreement is information. It usually points to an unclear requirement or a hidden dependency worth resolving before the work starts.