Story points

Introduction#

This article describes how to estimate the size of backlog items using story points and explains why this is desirable. It explains what a story point is, what it deliberately isn’t, and how we arrive at an estimate as a team.

What story points are#

Story points are a relative estimate of the size of backlog items such as User Stories, Bugs, Spikes, or Tech Improvements.

We estimate a story as “5 points” if it looks similar to other items we have previously sized as 5 points. Story points indicate how big items are relative to each other. The scale doesn’t map to a fixed amount of time and each team will have its own interpretation of what constitutes 5 points.

When assessing the size of an item, we consider:

How much work there is. Simple repetitive work can still take a long time if there is a lot of it.
How complex the work is. Fiddly or conceptually challenging work takes longer to implement right.
How uncertain we are about how the work will be done. The more we have to figure things out as we go, the longer it will likely take.

So when we say that complex or uncertain work is bigger, we do mean that it will typically take longer. What we don’t mean is that any particular person will spend any particular number of hours on it. The next section explains that distinction, because it’s subtle but important.

Story points represent all the work needed to complete the backlog item, including code review, testing, and merging code. They do not include idle time when the work is waiting between people, but do include any effort that will need to be spent interacting with others to agree or schedule the work.

Spikes are a special case. Rather than estimating how big the spike is, we use story points to timebox the effort we are willing to spend on it. A spike sized at 3 points means we stop after roughly the effort a 3 point item usually takes and report what we’ve learned, rather than continuing until we have a complete answer.

What story points are not#

Story points aren’t a fixed amount of time, but they aren’t divorced from time either. Across the whole team and over many items, a 5 point item does typically take around twice as long as a 2 point item. If that weren’t true, velocity would tell us nothing and we couldn’t forecast at all.

The difference is the direction we work in. We never convert points into hours when we estimate. We estimate story points, then observe how many story points the team actually completes each sprint, and forecast from that observed rate. The relationship between points and time is something we measure after the fact, not something we agree up front.

This matters because the moment a team fixes a conversion rate, say that a point is half a day, the estimate stops being a size and becomes a commitment about one person’s week. Every problem we were avoiding comes straight back.

Story points are also not comparable between teams and are only meaningful within a team. Two teams may both be estimating sensibly and still have quite different ideas of what a 5 looks like.

The Fibonacci scale#

Larger estimates naturally carry more uncertainty. To represent this, we restrict ourselves to using values from a modified Fibonacci scale, where the gaps are larger between larger numbers. The scale is: 1, 2, 3, 5, 8, 13, 20, 40, 100.

When estimating backlog items, we try to stick to scores of 8 or less and break items up if they are larger than this. Occasionally we may allow a 13 if we really can’t find a good way to split it, but that is a hard limit.

When estimating Epics we tend to use the larger sizes: 13, 20, 40, or 100.

How we define story points#

When first starting out, we need to figure out how big a story point is. We do this once, by anchoring against sample work items. We choose three items as reference points:

The smallest complete item we have actually delivered end to end, including review and testing. This defines the size of 1 story point. We deliberately don’t use something trivial like fixing a spelling mistake, because anchoring on near zero effort compresses the scale and leaves everything else looking like a 5 or an 8.
One that is medium sized. This is our definition of 5 story points.
One that is the largest we’d be willing to accept into a sprint. This sets our size for 13 story points.

We interpolate between these anchors for sizes 2, 3, and 8, and extrapolate for the larger sizes 20, 40, and 100. Over time we will internalise this scale, but initially we refer back to these anchor points to guide us.

How we estimate with story points#

We agree story point estimates using a process called planning poker. Everyone who could end up doing the work takes part, including testers and designers, not just the person most likely to pick the item up. The Product Owner joins the session to describe items and answer questions, but doesn’t estimate: the size is the team’s judgement of the work, not the sponsor’s.

The sequence for each item is:

Someone describes the item to the team and everyone else asks questions to ensure they understand what’s involved.
Everyone chooses an estimate privately, then all estimates are revealed at the same time. We round up: if we think the estimate should really be 6, we choose 8 rather than 5, to counteract the natural tendency to underestimate and because an overrun costs us more than finishing early does.
If the estimates agree, we record the number and move on.
If there is a roughly even split between two adjacent scores, then we choose the higher score.
If there is a wider spread, the highest and lowest estimators explain their thinking, and we re-estimate.

The process involves estimating privately and revealing simultaneously to prevent team members from influencing each other. We also don’t average the numbers or take a vote: we discuss until we converge, because the disagreement reveals useful insights and the conversation is valuable. Widely spread estimates almost always mean people are picturing different work, and that usually uncovers missing acceptance criteria, unstated assumptions, or unexpected dependencies. Resolving that during refinement is far cheaper than doing so mid-sprint.

Tips:

Timebox the discussion. If we can’t converge in a few minutes, the item usually needs breaking down, or we need to find something out before it can be sensibly estimated. That item should come out of the session and go back for more work before we try to estimate it again.
Plan with intent. Where knowledge or skills are siloed, estimates can vary a lot depending on who does the work: what is a 2 for the person who wrote the component might be an 8 for everyone else. We prefer to tackle this by building knowledge sharing into the work, typically by pairing, and to estimate on that basis. The silo gets smaller each time we do this and the estimates start to converge.

Story points in action#

We aim to break work down into small chunks of value, ideally 5 story points or less. See Feature Slicing for techniques to achieve this. This fine granularity means that work should move across the board quickly and makes it easy to see if an item is getting stuck or needs additional support.

It also means we don’t need any fine-grained tracking within an item, such as logging effort spent or revising how many points are left part way through. An item is either done or it isn’t, and if items are small enough, that’s a good enough signal on its own.

When working in sprints, if any items are in progress but not completed at the end of the sprint, we look again to see if we can split the item into a part that has been done and delivers some value and a part that can be carried forward. If so, we do this and re-estimate both parts. But if we’ve done a good job of breaking the work down into small chunks this may be unlikely, and if we can’t then we carry the whole item forward and count its story points in the next sprint instead.

Planning and forecasting#

Over a few sprints, we establish the team’s velocity: the number of story points the team typically completes each sprint. If there have been any team absences, then we factor that in when calculating the velocity.

The velocity allows us to forecast how many story points we expect to be able to complete in future sprints, again correcting for planned absences.

Together, this allows us to forecast several sprints ahead rough dates for when items may be done based on the current team and the current priority order. Sometimes this will highlight a problem, such as some items that are needed for a fixed date but look unlikely to be done by that date. This forecast gives us the information we need to reprioritise items or make other changes to solve that problem.

Why we don’t revise estimates after the fact#

If an item turns out to take longer or shorter than expected, we do not go back and change its estimate.

Correcting an estimate after the event treats normal variation as an error to be tidied away. Estimates are not perfect, and outliers in both directions are expected and completely normal. Editing them makes velocity a less reliable predictor, not a better one, because velocity only works if it reflects what actually happened, variation included. A velocity built from tidied-up estimates will systematically under-predict how much real work gets absorbed by surprises.

If large discrepancies are common rather than occasional, that’s worth raising in the retrospective and addressing as a team. The fix is better shared understanding of the work, not better arithmetic after the fact.

Why we estimate this way#

Story points naturally account for differing skill and experience levels. A size is a property of the item, so the estimate still holds whoever ends up doing the work. A time estimate has to be re-done, or quietly ignored, when the work moves to someone else.
They reduce the cognitive bias that leads to over optimistic estimation compared to time-based estimates. People are consistently poor at judging how long something will take in absolute terms, but reasonably good at judging that one thing is about twice the size of another. Relative sizing plays to the judgement we are better at.
They are quicker to produce. We don’t need to decompose an item into tasks and add up hours to say that it is roughly the size of that other thing we did last month.
They give us a basis for forecasting. Velocity measured over several sprints tells us what the team actually delivers, including the interruptions, review time, and rework that optimistic time estimates always leave out.
They make estimates a team activity. The number is the team’s view of the item, not an individual’s promise about their own week, which reduces the pressure to lowball.

Why estimation is worthwhile#

Doing good estimation takes time, and it’s reasonable to ask whether it’s time well spent. Two things make it worthwhile.

We saw in How we estimate with story points that the estimation process drives out misunderstandings and confusion that would otherwise only be discovered mid-sprint, where it’s more expensive and disruptive to fix. This investment in breaking work down and estimating it tends to accelerate delivery and improve quality overall. In practice, most of the effort goes into understanding the work well enough to break it down and get started on it. Once that’s done, the estimate itself is quick and easy.

We also saw in Planning and forecasting that estimates let us foresee scheduling problems while we still have time to take corrective action. Again, the investment tends to pay for itself.

Key points#

Story points represent the size of an item relative to other items, based on volume of work, complexity, and uncertainty.
A point is not a fixed amount of time or a promise about one person’s day, though sizes and durations do line up on average across the team over many items. That is what makes forecasting possible, and it’s why we measure the relationship rather than agreeing it up front.
Points don’t transfer between teams.
The estimate covers everything needed to finish the item, including review and testing.
We estimate as a team using planning poker, revealing estimates simultaneously to ensure we get the benefit of everyone’s untainted perspective.
Large estimates are a prompt to split the item or run a spike.
Where skills or knowledge are siloed, build in the work needed to share these as part of the estimate.
We never revise an estimate after the work is done, because velocity depends on estimates reflecting what we believed at the time.
The discussion an estimate provokes is valuable: it’s not just about putting a number on an item.