Story points are common in teams that follow Agile frameworks and especially so in teams where chaos is the preferred way of working, or where the team enjoy ideation more than development. As a concept, story points are flawed from the beginning and it has no value above traditional time - based estimations. In short story points are useless as indicators of time and, as such, pointless as measurements to support planning, which is the sole purpose of making estimates in the first place.

Why do we have story points to begin with?

Regardless of the origin of story points, which may have been born from good intentions, we now use story points to hide the fact that we have no idea what we are doing. What I mean by that is that it is common in Agile teams that the team take several work streams and try to do them all in one big process that is more chaotic than structured. So in order to handle everything from an idea to loosely defined business need all the way to a requirement at the same time, there is no way to actually have any planning or estimation.

Since all organizations need planning and financial steering, the story point was thrown in. While it does not really provide any of the information an organization needs, very few dared to say so out of fear of being seen as being stupid. So instead of getting values that the organization could use, the teams introduced an arbitrary value that is as useless as it is confusing. It became a way to avoid getting confronted for failing making time - based estimates and it has now become so ingrained in Agile that whole generations have lost the ability to work in any other way.

So why are story points so bad?

The answer to that is that story points do not provide the value that the organizations need. To explain what I mean by that, we should look at what we use story points for and why the organization needs that.

Estimations, why do we do them?

Story points are used for estimation, but what is an estimation really? Some people make the claim that an estimation is a guess, which is not true. A guess is if I pick up a random card from a deck of cards and ask you to tell me what card that is. Unless you have telepathic powers, you will have a random chance to get it right based on the number of cards in the deck.  An estimate, on the other hand, is a prediction based on previous experience and your level of understanding of your craft.

The way we use the estimates is for planning and for financial decisions. While this is, of course, something that affects the team, it is more important outside the team. That is because planning and making financial decisions are needed for coordination and for organization wide planning.

Estimations require understanding

In order for you to be able to make an estimation, you must first understand what you are going to do. The less you understand what the work is that needs to be estimated, the less accurate your estimation becomes. This is why in most processes you have 3 stages of estimation. These three stages are naturally formed around the three financial decisions that are made for any work that is done in development. The stages are:

1. Stage 1 - Ideation
2. Stage 2 - Investigation
3. Stage 3 - Detailing

Ideation to explore new ideas and theories

In Ideation, we explore ideas and theories for what could become good additions to our products and services. This is the domain of UX and UI with support of development when needed. In this phase we spend money to find new ways to enhance our existing products and services, but also to explore new ones. This phase never works with estimates as the work is creative and exploratory. Instead, this phase has time limits on how much time is spent exploring different ideas and theories.

Investigation to prioritize and plan

The investigation phase is where we have ideas and theories that we want to pursue further. In this phase we are dealing with business needs that can be any size, ranging from a feature to entire programs. It is in this phase that we first estimate work and at this level we use high estimates. High estimates are just that, something we estimate with limited information on what the work entails. Since this limited knowledge means that there is a lot of risk involved, high estimates are always high. This is to compensate for the risk and for the time needed to break down the business need to requirements.

Detailing to make it clear enough to build

The last step is where we actually need to make detailed estimates and this is where first add time based estimates, or story points. The goal when going into requirements is to break down the work to ensure we know enough of the solution design that we can make realistic estimates. We also do this to ensure any obvious question is answered, so everyone can agree on what should be done to solve the need (or problem if you prefer that term).

When you mix all three stages into one...

As you can probably tell, it is not a good idea to mix all three of these stages into one and there is no natural way to do so if you consider the way we actually work. While all three stages exist in the context of a team, or rather in the context of a single product or service, you always go through these three stages.

If someone comes up with a good idea, then the owner of the budget needs to know if it is worth spending money on it or not. To do that, an estimate is needed and if the value is higher than the cost, it goes into detailing and then into development. In the event the idea is too big, it will go up for financing at a higher level before it comes down again to the team.

Well, why are story points bad then?

Patience grasshopper, first we must understand how estimates are used outside the team. In order to explain this we need to make a few examples of companies since we do this differently in different organizations.

The Small Startup

The small startup is a company with less than 50 people that are all located locally. Everyone knows each other by name that all sit together and work closely together towards a single goal. There are 3–4 teams all working on the same product or service and they all work towards cloud based tools and services. The company focus on the here and now to get their product or service to become successful.

The Medium Large Company

The medium large company has 4000 employees where 2000 work in IT. The company has offices and workforces in 12 countries. It has around 150 teams working around hundreds of systems that are hosted both internally and in the cloud. There are around 50 organization wide projects happening at any given time and the company employs around 700 external consultants annually to support projects and teams. The company focuses on annual plans, but also has 3-year plans and 5-year plans where things like new products and services are mapped out together with expansion plans and strategic plans.

How do estimates impact the companies' ability to plan?

In the small startup there is really no need for estimates at the size they are at. Coordination between the teams can just use target dates and rough roadmaps that the whole company can work with daily. Collaboration is easy and adding time to create story points is probably just a waste. Work is a bit chaotic and people that want structure usually leave within a year or two. Once the small startup grows and the need for estimates becomes more apparent, this leads to growing pains. The old ways no longer work and no one has the experience or knowledge of how to transition to a more structured way of estimating work.

In the medium large company, estimations are crucial to managing both projects and consultant contracts. Delays cost in the millions and affect hundreds of people in a cascading fashion. Teams that fail to deliver realistic estimates often see a big spike in micromanagement, or the team is simply replaced with people that can estimate better. In an attempt to reduce failed estimation impact, the company introduces restrictive processes to force estimations. This leads to an overly rigid and unflexible work environment that is painful for those that want a more flexible and creative setting.

Seriously though...what about story points!?

Now that we know what we need estimations for, let us talk about why story points are not a very good way to provide that value to the organizations. Let us start with what a story point is.

What is a story point?

In short, a story point is an arbitrary value used to compare tasks internally. This is a mouthful, so let us use an example to make it a bit clearer. Let's say that we have three teams all using story points, so when they begin estimating, it looks something like this. We are assuming that they use the Fibonacci sequence as well since it is a common way when using story points.

Team 1 starts by assigning 1 story point to a task. Just for illustration, we'll add a time based value to it to illustrate. This 1 story point turn out to be 1 hour. The next task is then measured against this task and it is decided that it is larger, so it becomes a 2-story point task. It turns out to be 4 hours in time. As they continue, they end up with something like this:

• 1 point = 1h (1)
• 2 points = 4h (2)
• 3 points = 8h (2.7)
• 5 points = 14h (2.8)
• 8 points = 26h (3.3)
• 13 points = 48h (3.7)

Team 2 do the same thing, but their values are different:

• 1 point = 30m (0,5)
• 2 points = 2h (1)
• 3 points = 6h (2)
• 5 points = 10h (2)
• 8 points = 18h (2.3)
• 13 points = 28h (2,2)

Team 3 also has a different set of values:

• 1 point = 8h (8)
• 2 points = 16h (8)
• 3 points = 24h (8)
• 5 points = 40h (8)
• 8 points = 60h (7.5)
• 13 points = 80h (6.15)

Each team has 10 team members with the same salary of $100/hour just to make it easy to calculate. We assume each team has an effectiveness of 50% because they get dragged into meetings, do pull requests and help each other out when needed. This means that each team can do 200h of work each week, at the cost of $40.000.

What does that mean in terms of story points?

Well, this is where things get complicated because a story point is not a single value, it is a span of values. A 5 story point task for team 1 for example is anywhere between 8 hours and 14 hours. It also have no relation to other points, meaning that we can not summarize multiple story points and get the correct value. There is simply no 1-1 relation between the point value and the time they represent.

So 200 hours for team 1 would vary between 54 and 200 points. For team 2 it would be between 87 and 400 points. For team 3 it would be between 25 and 33 story points.

This would mean that the cost for each story point varies in the teams where team 1 would have a cost of between $741 and $200 for each story point. Team 2 would have a span of $460 and $100 per story point and team 3 would have between $1600 and $1212 per story point.

At least that is what we would assume if storypoints always measured as a fixed value, but we already established that this is not the case. That means that the avriables will fluctuate even further as each story point would be a span of time rather than a fixed value.

As you can see there is also no way to use story points from the three teams since the values are not the same even between the teams. To be fair in many cases the difference between teams are not as big as the ones I have presented here, but I think you see the problem regardless.

What is we make story points the same then?

It is not uncommon to see teams getting tired of answering the question "how many hours is that", which is always going to come if the organization need to time to make financial decisions and any large scale planning. This is when they start conforming their story points so each story point is x amount of time. This is extra sad because what they have done then is just added a label to their time based estimation! It no longer have any purpose other then to confuse people.

Is there no way you can use story points then?

If your aim is to help your organization and they need estimates for planning and prioritization, then no.  There is no way, as far as I know, where story points would be valuable for that purpose.

If you use them for other purposes, like to have the developers start talking about solution design as suggested by Josh Anderson in the great episode of Agile for Humans, then only your imagination set the limit for what you can use them for. As long as you know that you are not making estimates for your organization to use, then use it for whatever you want.

This sucks, the organization must change so we can use story points!

Many Agile teams get mad when presenting this to them and they insist that the reason story point doesn’t work is because the organization is not Agile. That point is rather moot since you must work with the existing organizations and because of the way financial structures exist in businesses that objection does not really mean much. There is a reason why Agile frameworks don't scale and that is because they are all team based.

At least this is the situation today.

Maybe tomorrow we will change how companies focus on profit and maybe we no longer have the need to plan and prioritize. Maybe we will no longer have large companies, but small cells of teams that are all financially independent somehow.  Maybe something will come along and revolutionize companies, and this will make story points viable again. Who knows.

Today, however, you should not use story points.