The Agile Estimation Handbook

What are story points?

Story points are a unit of measure for expressing the overall effort required to fully implement a product backlog item or any other piece of work. They combine complexity, volume, and uncertainty into a single relative number.

Unlike hours, story points don't decay. A "5" story that took 4 hours this sprint will still be a "5" next sprint — even if a different team member picks it up. This consistency is what makes velocity a reliable planning metric over time.

Relative sizing vs. absolute estimates

Absolute estimates ask: "How long will this take?" Relative sizing asks: "How does this compare to that?"

Humans are notoriously bad at absolute time estimation. We're much better at comparison. We can reliably say "Story B is about twice as complex as Story A" even when we can't say "Story B will take exactly 6 hours."

Practical tip: Establish a set of reference stories — 2-3 stories the team has already completed that serve as anchors for your scale. A new story that feels similar to your reference "3" should be estimated as a 3, regardless of how long it actually takes in hours.

Velocity: what it is and how to use it

Velocity is the average number of story points a team completes per sprint. It is calculated over multiple sprints (typically 3–5) to smooth out anomalies like holidays, sick days, or unusually complex stories.

• Sprint 1: 24 points
• Sprint 2: 31 points
• Sprint 3: 27 points
• Average velocity: 27 points

With a velocity of 27, the team can commit to roughly 25–30 points of work per sprint. Use the lower bound for planning when uncertainty is high; the upper bound when the team is stable and the stories are well-understood.

Important: Never use velocity to pressure a team into doing more. It is a planning tool, not a performance metric.

Common mistakes in sprint planning

• Estimating tasks instead of stories. Estimation sessions are about user-facing value and complexity — not implementation details. If your team is estimating individual subtasks, you've gone too low.
• Letting one voice dominate. When the tech lead or product owner speaks first, the team anchors to their estimate. Use simultaneous reveal (planning poker) to prevent this.
• Estimating stories that aren't ready. A story without a clear acceptance criteria is not ready to estimate. Return it to the backlog.
• Splitting stories mid-session. If a story turns out to be too large during estimation, add it to the backlog for refinement — don't try to split it in real time.
• Ignoring the "?" card. When team members play the question mark, that's critical signal. Stop and clarify before re-estimating.

Tips for better estimates

1. Use reference stories

Pick 3–5 completed stories that span your scale (a "1", a "3", an "8"). Keep them visible during estimation sessions as calibration anchors.

2. Timebox your discussions

Set a timer. If the team hasn't reached consensus after two rounds of voting, the lead estimators explain their reasoning, the team votes once more, and the majority wins. Perfect is the enemy of done.

3. Estimate as a full team

Include everyone who will actually do the work — developers, designers, QA. Different perspectives surface hidden complexity and reduce surprises during implementation.

4. Track and review

At the retrospective, compare estimates to actuals. Not to punish — to improve. Patterns emerge: your team consistently underestimates UI work, or overestimates backend tasks. Use this to recalibrate.

5. Keep your backlog refined

Estimation sessions go faster when stories are well-written and the team already has shared context. Invest time in backlog refinement meetings (typically 1–2 hours per sprint).

How Estimr fits in

Estimr is built specifically for agile teams that want to run clean, distraction-free estimation sessions — whether the team is in a room together or spread across time zones.

• Simultaneous card reveal prevents anchoring bias
• Session history lets you compare estimates to completed stories
• Team Backlog connects your planning sessions to the work being estimated
• No account needed for participants — lower friction means higher attendance