Estimation and planning: story points and velocity

Anyone who has ever said "I'll get it done in two days" knows how that ends. Two days pass, and the task is half done, because a forgotten edge case surfaced, a neighboring service broke, or a meeting you couldn't skip got in the way. An estimate in hours looks precise, but that precision is deceptive: we're bad at predicting time, yet we're pretty good at sensing that one task is bigger than another. Agile estimation is built on exactly that observation — story points, Planning Poker, and velocity. Let's look at how it works and, more importantly, where teams most often stumble.

Why estimating in hours misleads

Estimating in hours feels natural: the customer asks "when," and we answer "in so many hours." The problem is that absolute time depends on a pile of things that are unknown at the moment of estimation.

• Different people — different speed. A task an experienced developer closes in an hour takes a newcomer a whole day. Whose estimate do you put in the plan?
• Uncertainty hides in the details. "Add a field to the form" sounds like 15 minutes, until it turns out the field has to be validated, saved in two places, and shown in a report.
• Breaks and context switches get in the way. A real workday is not eight hours of pure code. Meetings, discussions, helping a colleague. An estimate in hours pretends none of that exists.
• The number becomes a promise. Say "4 hours" and it turns into a commitment, one you supposedly should feel ashamed to miss — even though you were only guessing.

The key idea of Agile estimation: we're far better at comparing than at measuring. Ask how many minutes it takes to walk to the store — the answers will scatter. Ask which is farther, the store or the park — and everyone answers the same. That's relative estimation: not "how much time," but "how much bigger compared to something familiar."

Story points — estimating complexity and size relative to a reference

Story points are conventional units the team uses to measure not time, but the overall "size" of a task: how much work is in it, how complex it is, how much uncertainty and risk it carries. There are no exact hours in points, and there shouldn't be.

Here's how it works. The team picks a reference task — a small, clear one that everyone has done and understands well. It's assigned, say, 2 points. Then every new task is compared against the reference: "this is roughly like the reference" → 2, "about three times bigger and with a murky chunk" → 5 or 8.

Usually you don't use consecutive numbers, but a sequence where the step grows — for example, the Fibonacci sequence:

The growing step is no accident. The bigger a task, the worse we understand it, so estimation accuracy drops too — distinguishing "21 or 22" is pointless, while "13 or 21" is meaningful. If a task looks like 13 or more, that's a signal to split it into several smaller ones: large estimates almost always hide undissected details.

An important property of points: they're "local" to each team. A five in one team and a five in another are not the same thing, because everyone's reference differs. Comparing points across teams is pointless (we'll come back to this).

Planning Poker — the team estimates together

Estimating alone is dangerous: one person sees only their slice of the work. Planning Poker is a simple ritual that forces everyone to speak up.

It goes like this:

1. The facilitator reads out the task, the team asks questions until the meaning is clear.
2. Each participant secretly picks an estimate — a card from the deck (1, 2, 3, 5, 8, 13…) or with their fingers.
3. Everyone reveals their choice at the same time — so nobody adjusts to an "authoritative" colleague.
4. If the estimates are close — take a common one and move on.
5. If they diverge sharply (someone put 2, someone put 13) — discuss precisely that divergence.

The most valuable thing here is not the number, but the divergence. It almost always means people understood the task differently. The one who put 2 doesn't know about the integration with the legacy system. The one who put 13 remembers how last time it took a week. The conversation pulls hidden assumptions and risks to the surface — and often it's here that it turns out the task needs to be reframed entirely. Estimates that match on the first try are, by contrast, boring: they bring no new information.

Simultaneous reveal is no small thing either. If the loudest or the most senior person speaks first, everyone else adjusts, and the discussion loses its point. A secret choice preserves independent opinions.

Velocity — how much the team closes per sprint

You estimated the tasks in points, took them into the sprint, and got them done. The sum of points of the tasks completed in a sprint is called velocity. If in a sprint you closed tasks worth 8, 5, 3, and 5 points, that sprint's velocity is 21.

A single number tells you nothing, but several in a row do. Take the last few sprints: 19, 22, 20, 21, 18. You can see the team steadily closes around 20 points. That's the working planning tool: there are 100 points of tasks left in the backlog → at a velocity of ~20, it will take about five sprints. Not a guarantee, but a grounded forecast that gets refined over time.

Velocity naturally "floats" from sprint to sprint — illnesses, vacations, holiday weeks, a tough task that came up. That's why you rely not on the last number, but on the average over several sprints, and treat it as a range, not a point. For a new team, velocity isn't available at all for the first few sprints — it simply has nothing to compare against; the reference and rhythm haven't settled yet.

And the main thing worth keeping velocity for: it's a forecasting tool for the team itself, not an assessment of its work for someone up the chain. The moment velocity is demanded to "go up" — it breaks.

Common mistakes

Let's go through the pitfalls teams step on most often.

Points get turned into hours. "5 points is about a day, right?" Introduce a conversion table like that, and the whole point of relative estimation vanishes. Points become time again, with all of time's problems. Points stay points: you don't convert them into hours, you only use them to compare tasks against each other.

Velocity gets used as a productivity metric. "Last sprint it was 20, this one 18 — did we get worse?" No. Velocity depends on which tasks came up and how they were estimated. It's easy to "motivate" a team — it starts inflating estimates, and velocity climbs nicely, even though the same amount of work got done. The number will grow, the value will fall. As soon as velocity becomes a goal, it stops being an honest measurement (this is the classic effect: any metric that becomes a target gets corrupted).

Velocity gets compared across teams. "That team's velocity is 40, ours is 20 — they're twice as fast." That's nonsense: each team's points are their own, the references differ. Comparing their velocity is like comparing height in different, unknown units. Velocity is meaningful only within a single team and only over time.

Estimating for the sake of estimating. Sometimes a team spends hours polishing estimates for tasks it won't get to for another six months and which will change ten times by then. An estimate is needed to make a decision — whether to take it into the sprint, whether we'll make the deadline. If the decision doesn't depend on the estimate's precision, detailed estimation is just wasted time.

There's also a radical alternative — the #NoEstimates approach. Its idea: if the backlog tasks are broken into sufficiently small and roughly uniform pieces, you can skip estimating them in points altogether and just count the number of tasks completed over a period. Things split to a comparable size close at a similar pace, so counting tasks gives a forecast no worse than velocity, but without the estimation ritual. The approach isn't universal — it demands discipline in breaking tasks down — but it's useful as a reminder: estimation is not an end in itself, but a means. If counting tasks answers the question "when will we make it," elaborate estimation may not be needed at all.

In short

• Estimating in hours is deceptive: time depends on the person doing the work, hidden details, and breaks; we're better at comparing tasks than at measuring them.
• Story points estimate a task's size (volume, complexity, risk) relative to a reference task, not time; a scale with a growing step (the Fibonacci sequence) reflects the drop in accuracy on large tasks.
• Planning Poker is a secret, simultaneous estimate by the whole team; the value is in the divergences, which expose different understandings of the task and its risks.
• Velocity is the sum of points closed in a sprint; the average over several sprints is used to build a forecast ("how many sprints for the remaining backlog"), not an exact guarantee.
• Velocity is a forecasting tool for the team itself, not a KPI: the moment it's demanded to "go up," estimates get inflated and the number loses its meaning.
• Points must not be converted into hours, nor velocity compared across teams: both are meaningful only within a single team.
• Don't estimate for the sake of estimating; the #NoEstimates alternative proposes counting the number of small, uniform tasks instead of points.

What to read next

• Scrum — sprints, roles, and rituals in which estimation and velocity live.
• Kanban — flow without sprints, where instead of velocity you look at throughput and lead time.