I need to go on the public record about story points. The only place story points make sense is when you’re trying to make an unfamiliar team comfortable or obscure the realities of software development from management. In every other case you are better off estimating in days or saying “I don’t know, it’s not knowable, we need to do some research, a prototype or more design work”.
I know this is a controversial position so I need to ask you to go on a journey with me and take the argument I’m about to lay out on its merits. So far, those that come on the journey end up changing their minds. At the very least, even if you don’t end up agreeing I hope you find some insight. Maybe you’ll be the one to convince me otherwise, I’m definitely open to it.
I’ve purposefully left out any posturing of why my experience matters because an argument needs to stand on its merits.
Let’s get into it.
What are story points used for
Story points are supposed to give teams a way of estimating the work they need to do and communicating their work with stakeholders.
This seems great on the surface. Smart people have invented a smart concept to represent the complications inherent in software development.
Being driven by an engineering mindset we all pat ourselves on the back for inventing some great algorithm that abstracts into a better model the work that we do.
I can’t help thinking about the financial geniuses that abstracted away mortgage risk and repackaged it with their brilliant models. Only to end up creating one of the greatest financial crises humankind has seen in 2008 because they had obscured reality.
The reality is though, work is done by people in the normal time and space of the universe. Story points are just a proxy for time, duration or effort. Complexity is a somewhat separate concept altogether that is either resolvable with time or not.
It’s at about this point in the conversation that someone says “yeah but…” and then they present an argument as to why story points are necessary.
Why story points don’t work
So let’s walk through each of the reasons why people say story points are superior to using the actual unit of work (time) and refute each one-by-one.
- Software development is uncertain or complex, this task is uncertain or complex – the first argument that is almost always put forward in this conversation is some variation on how software development contains complexity and uncertainty that just cannot be known. Story points deal with this. Bullshit. If something is uncertain or risky then you’re kidding yourself, your team and management to provide certainty. Break the task down further so it can be certain, isolate the uncertainty. Do more research in a timeboxed way so you can get certainty. Just say “I don’t know” don’t say “8 story points” because the latter is just lazy thinking, lazy expectation management. The former explains reality and you need to deal with reality.
- Management was taking our days of effort estimates and converting that into due dates. This just means you or your engineering manager isn’t communicating that effort is not equal to duration. They are two different concepts. Estimating duration takes effort into account but must also take resourcing, meetings, annual leave, team churn, etc into account.
- Story points are a better representation of team achievement. Team achievement needs to be focused on actual outcomes delivered for the business, revenue improved, retention improved, customer satisfied, costs saved, delivery times improved. You could have churned through 465 story points but all of it on semi-useless low priority tasks but the number seems high so provides a false sense of achievement.
- We need to size the work quickly. This is one of the better arguments but it still falls down. The argument goes something like “we need to quickly get a sense of how hard work will be so that we can prioritise and plan”. Makes sense on the surface but when you dig into the use of story points for this then you end up hearing that every team member just translates the story points back to either (a) days effort in their heads (e.g. 8 story points equals 3 days) or (b) easy, medium or hard in terms of complexity. If this is what is happening, then do you need a layer of abstraction in the form of story points? Just use (a) or (b). It will be faster to do this, easier to communicate with each other and easier to communicate with people external to the team or new to the team.
- Things don’t usually turn out as expected. This is probably one of my most disliked responses. The implied argument is “my profession is building software but I can’t tell you how long it will take me to complete things, even though I’m an expert at said things because like it’s a creative process or something”. Bullshit. My artist friends can tell you how long it will take to paint a painting. How long it will take to write a book. You’re trying to tell me you can’t estimate how long it will take to put a button on a screen like you’ve allegedly done 47 times before. If you’re now claiming uncertainty, complexity or difficulty then see argument (1) above. But by now we’re dealing with small tasks that are knowable and certain. Yes, things won’t happen as expected. You’ll be wrong. I significantly overestimated how long it would take to write this post (I thought 4-8 hours, it took much less). Getting estimates wrong is what good engineering managers apply contingency for. You need to take responsibility and improve your understanding of what you can get done with how much effort.
- It’s easier to get the team estimating in story points. Usually this comes down to the people estimating being worried that they will be held accountable to their estimates. They should be worried, if you aren’t accountable to your teammates then there is something wrong. If you’ve followed the points above and you have understanding management then your team should relish accountability. High performing teams love accountability. To do this just to placate people because you don’t want to address the real issues in the team is lazy.
- We had too much pressure from management. This is the only legitimate argument, so I’ll dig into it further down in the article.
The core argument I always return to is that everyone I have interviewed about this topic tells me secretly (almost as a whisper as though they’ve just committed a crime), “look actually Scott I just translate story points to days effort in my head.” Everyone just ends up in some kind of translation like: 4 points means 1 day, 8 points means 3-5 days, 16 points means 5-10 days.
Two legitimate uses
Obscuring the software development process from management
The most legitimate use case for story points that I’ve heard is that teams need to obscure the details of the software development process from management. Usually management is exerting unnecessary pressure on the team, micro-managing (“you said 2 days on task X, where is it?”) or applying unhelpful deadlines onto the team. Not every organisation has management and executives that understand the software process.
In this instance, the use of story points makes sense as a tool for managing expectations and shielding the team from interference so that the team can get on with achieving what they need to achieve. But let’s call it what it is.
This is a perfectly acceptable use case. Over the long run you may want to work on changing the culture or educating your stakeholders.
Creating a safe environment for the team to estimate
Story points might also be used to give individuals or an entire team comfort so that they can make estimates. Having an estimate, even if it is in story points, is almost always better than no estimate.
Engineers will often be nervous giving estimates in days because they’ve been burned in the past so in order to get the team moving and get visibility over the magnitude of work in front of your team it might be necessary to use points. This is usually either because they are familiar with it or because they believe points is less likely to cause trouble for them. There is also something about using a manufactured concept like story points that makes it easier to estimate in some instances, especially for teams unfamiliar with each other.
In the long run, for the reasons outlined earlier in this post, you want to consider moving away from points once people build familiarity in order to get down into the underlying reality of the situation.
A final word
The use of story points is mostly people overthinking something simple or avoiding taking responsibility for their capability, which is being able to do what you say you will do.
This has led me to the conclusion that estimates are best done in days effort, then translated by a competent person into duration and timelines.
Days are easier to communicate with everyone. Easier to reflect on (did my estimate work? Why not? How can I improve?). Easier to manage expectations with. Estimating in days just makes sense.