Agile estimation: the complete guide
A practical guide to agile estimation: user stories, planning poker, story points, velocity, and the techniques that hold up when a story turns out bigger than it looked.
Planning poker is a consensus-based agile estimation technique: teams vote privately, reveal every card at once, and discuss the spread until the estimates converge.
How to run a planning poker session that gives useful estimates without dragging: prep, the four-phase round, choosing a deck, and ruthless time-boxing.
Story points measure the relative effort, complexity and uncertainty of work — not hours. How to size against a reference story, and the questions that trip teams up.
Story points climb 1, 2, 3, 5, 8, 13 because the widening gaps encode uncertainty — the scale stops pretending you can tell a 13 from a 14. Here's why the gaps are the point.
Story points measure relative effort; hours measure duration — different axes. Build a points-to-hours table and you've quietly gone back to estimating time.
Velocity is the story points a team completes per sprint, averaged. What it's for, why it breaks the moment it becomes a target, and how to keep it honest.
People are bad at 'how long will this take' and good at 'is this bigger than that.' Relative estimation uses the second — and it's why story points work.
Early estimates are wide because the work is unknown, not because your team is bad at estimating. What the cone of uncertainty means, and how to narrow it — not pad it.
Epics, stories and tasks are three tiers with three jobs. What each is, which one carries story points, and why pointing the wrong tier makes velocity meaningless.
Agile estimation techniques compared — planning poker, T-shirt sizing, buckets, dot voting, affinity and magic estimation, and the failure mode each one hides.
The recurring ways planning poker sessions go wrong — averaging cards, estimating in hours, weaponized velocity, story-point inflation — and how to fix each.
Acceptance criteria are a story's pass/fail test, written before work starts — the formats that work, worked examples, and how they differ from the definition of done.
The definition of done is one team-wide checklist every story clears before it ships. A sample DoD, who owns it, and how it differs from acceptance criteria.
The definition of ready is the checklist that says a story is sprintable. What a useful one covers, why most get ignored, and the version that actually blocks.
A story you can't estimate is usually one you can't ship yet. How to tell when to split, the cut lines that produce shippable slices, and the ones that only fake it.
SPIDR is five reliable ways to split a user story — spike, path, interface, data, rules. Each cut line, when it works, and when it produces a fake slice.
Vertical slices ship value; horizontal slices ship promises. Why splitting by tech layer defers value, and how to slice by user outcome so something ships each sprint.
A user story is a short, plain-language promise of value. The role-goal-benefit format, the three Cs, the INVEST checklist, and the cases where stories are the wrong tool.
Sixteen user story examples across auth, e-commerce, mobile, APIs and bugs — each annotated, with the bad versions shown next to their rewrites so the difference is visible.
The classic user story template with a copy-paste card, the variants worth knowing, and one worked example carried from template to acceptance criteria to estimate.