Story points aren’t real

2024-01-18, 2024-02-03

Story points are often a necessary evil in “agile” software development. Software delivery is tricky and is fraught with uncertainties. Stakeholders, in their desperate quest for a deterministic model of the universe, or at least one they’re not responsible for, get nervous of this fact and simply want to know “when will it be done?”

Story points can be kind of helpful here. They don’t provide concrete answers, but by at least giving an answer everyone is equally unhappy with, the conversation can move on to more important, equally unanswerable, questions like “what is it you actually want us to build?”

You might use story points in your day-to-day. If you do, it’s worth keeping the following in mind.

They’re not real

Story points are local to a team and are local in time. Their meaning will differ between teams, even if those teams are closely related. As time goes on, teams evolve and mature, the system under development shifts beneath your feet, or people come and go, what is meant by “a 2” will change.

Don’t ever try and make them real. Never use story points in contracts, as a currency, a bargaining chip, or when reporting anything to anyone outside the team that is using those points. They don’t mean anything without context and will only confuse people.

They’re actually a measure of probability

Story points don’t describe the amount of the time it will take to complete any given story. Instead, they help you to understand the likelihood of a piece of work being completed within a set timeframe. If you have a 13-point story to complete, but the team thinks they only have capacity for 8 points, it’s unlikely that it will be completed in time. However, if you have 4 2-point stories, there’s a high chance that most, maybe even all, of them will get done.

FogBugz’ Evidence Based Scheduling is a good, non-story point illustration of this. Jira has a similar feature.

They’re a tool for developers

It’s important to remember that story points aren’t a tool used to manage development teams. They’re really a tool used by development teams to manage their stakeholders. If you’re arguing with a development team that a 5 pointer is actually a 3 pointer, you’ve already lost. It won’t affect the amount of work to be done, it’ll just give you a false sense of security.

Used well, they can help you make better decisions

Used responsibly, story points can help you to spot patterns and inform your choices. Velocity unexpectedly trending down? Speak to your team to find out what might be affecting them. You absolutely must get this 13-point story done by the end of Q1 but there’s only capacity for 8? Check to see if any scope can be dropped or go set expectations with your stakeholders.

They are most inaccurate when a team is new, but that’s when they’re most useful

While teams are forming, or relationships with stakeholders are being built, story points can be a shortcut to creating a shared understanding. During this time, when a team knows the least about the system they’re building (and about each other), their estimates are likely to be well off the mark. However, they can provide a framework for a team to reason about the problems they’re facing (e.g. “why did this, seemingly simple, 2-point story take 3 iterations?”).

As time goes on, everyone’s sensing for the health, capabilities, and needs of the team will form. With careful management, the theory of the system is constructed, trust is built, and estimates start to converge.

Once in this state work can flow well. You might find that most estimates become “a 3” (or whatever value the team allots a story that can easily fit in their heads) and can be safely ignored. At least until the next disruption comes along and throws everyone out of balance.