Story points explained

Why not hours

Hours are personal. The same work takes two engineers different amounts of time. An estimate in hours always means “how long this would take me”, yet it gets treated as everyone’s number.

Hours also sound like a promise. You say “six hours”, and the next day someone asks why it is not done. Between the estimate and the finished item there is still review, testing, other people’s blockers and support interruptions.

Points avoid this problem. A point says this item is about twice the size of that one. The team can check and challenge that claim, and nobody has to justify themselves.

What size is made of

A point covers more than the amount of code. Three things go into it, and confusion starts when people only remember the first.

• Volume: how much there is to do. Screens, fields, cases, tests.
• Complexity: how hard it is. An unfamiliar area, tricky logic, someone else’s code.
• Uncertainty: how much is unknown. An external service that may behave in unexpected ways, or requirements that are still being clarified.

Where to start: a reference item

A unit means nothing on its own, so the team needs a reference. Pick an item everyone remembers: small, but not trivial. Give it, say, a two, and compare everything else to it.

It helps to have two or three references of different sizes: one for a two, one for a five, one for an eight. With three reference points a new item is easier to place than with one.

References change over time. Six months later a former five may become a two because the area is now familiar. That is fine, but rescale the whole scale at once rather than one item at a time.

How velocity comes out of points

Velocity is the sum of points for items finished in a sprint. Only finished work counts. A half-done item adds nothing.

The number starts to mean something around the third or fourth sprint, when the average and the spread are visible. Then planning becomes simple arithmetic: “We usually take forty, the backlog has fifty-five, so something won’t fit.”

Velocity is for forecasting. If people get praised or blamed for it, points inflate. The team won’t work any faster, but it will start estimating more generously by the next sprint.

What not to do with points

A few habits make points useless.

• Converting points into hours. A rule like “one point is four hours” takes you back to estimating in hours.
• Comparing velocity across teams. Each team has its own scale.
• Making velocity a goal. If the number goes up while output stays the same, the metric is being gamed.
• Measuring people in points. You estimate the item, not the person who took it.
• Changing an estimate after the fact. It shows what was known at the time, and that is why it is useful for forecasting.

How many points is too many

If a team sizes an item above eight, it probably does not fully understand it. Such an item is better split into parts. Large items are not forbidden, but they contain too many unknowns for a reliable estimate.

A good rule: an item should fit into a sprint with room to spare. If it takes the whole sprint, any surprise leaves the team with nothing finished.