How Story Points Turned to the Dark Side
It All Started with Good Intentions…
Story Points started with good intentions. Let’s start with a short history lesson to remind ourselves where good intentions can take us.
In the 1930s, the sugar cane industry in Australia was plagued by a pesky insect eroding sugar yields and threatening profits. The culprit was the larvae of the common sugar cane beetle that would destroy sugar cane plants by chewing on their roots.
In a desperate attempt to control the prevalent sugar cane beetle, the government released an exotic Puerto Rican toad, Bufo marinus, in Australia.
The thinking was as follows: the toad eats the sugar cane beetle, the beetles can’t chomp any roots, thus allowing the sugar cane to grow prolifically.
Cue to making massive sugar profits 💰💰💰 and everyone being happy 🌈🌈🌈!
Yeah, that’s exactly what didn’t happen. The introduction of the toad turned into a complete nightmare.
The slimy creature was a formidable enemy not only to the sugar cane beetle but to any other animal present on the continent. The toad spread like wildfire and was declared a national problem species in the 1950s.
The problem was that the warty amphibian was poisonous (including its tadpole offspring) and had a voracious omnivore appetite to boot.
Picture a 15 cm (6 inches) jumping stomach on legs jumping around and eating anything that fits in its mouth. No animal could touch it without dying from poison. If only it ate rabbits too… 🐇
The case of the toad and the sugar cane beetle rose to such infamy, that it suddenly went by a new moniker of Cane toad all over the world.
The introduction of the Cane toad started with good intentions but ended in an ecological nightmare that still isn’t under control.
As the saying goes:
“The road to hell is paved with good intentions.”
The same happened with the good intentions of Story Points. Even the Story Points inventor Ron Jeffries has declared:
“I like to say that I may have invented story points, and if I did, I’m sorry now. — Ron Jeffries”
Let’s start by chronicling the good intentions behind Story Points.
Story Points have their origin in Ideal Days
Ron Jeffries started by estimating work in time — ideal days, as he learned from XP. Imagine you would have no interruptions and nobody would bother you. In such an idealized case, how long would it take you to complete the work? That’s your estimate in ideal days. Effectively this is a time estimate.
There was only one problem with this estimation method: management didn’t get it. In the words of Ron Jeffries:
We multiplied Ideal Days by a “load factor” to convert to actual implementation time. Load factor tended to be about three: three real days to get an Ideal Day’s work done.
We spoke of our estimates in days, usually leaving “ideal” out. The result was that our stakeholders were often confused by how it could keep taking three days to get a day’s work done, or, looking at the other side of the coin, why we couldn’t do 50 “days” of work in three weeks.
Story Points started as Ideal Days multiplied with a load factor of 3.
Have you ever heard of Mushroom Management? It’s a form of management where the goal is to obfuscate information and communicate as little information as possible. As a result, nobody knows what is going on except management. you can summarize Mushroom Management aptly as feed ‘em shit and keep them in the dark.
Story Points are a form of Mushroom Management, except it’s the developers who conceal information from their managers by making it less transparent how they spend their time.
Now you know the idea behind Story Points to help protect developers from being bullied with time estimates by managers. Let’s talk about why these good intentions backfired.
Story Points are difficult to understand
Few people seem to understand Story Points. It becomes worse the higher up we travel in the organization. When I hear people talking about Story Points, I often think: “What the hell are they on about?”.
Here are a few everyday conversations about Story Points:
“Story Points are about complexity.”
“How many days is 1 Story Point?”
“You shouldn’t Story Point bugs or things that don’t have any immediate business value.”
“ Spikes are time-boxed and thus you cannot Story Point them.”
Let’s end the misconception once and for all: Story Points have their origin in Ideal Days and represent an unknown amount of time. Complexity, uncertainty, and risk may influence effort, but each alone is not enough to determine the amount of time something takes.
And if you disagree with me and believe I am wrong, then it still proves my point — Story Points are difficult to understand.
Story Point confusion has forced me to listen to many pointless conversations about them over the years. But that’s not the biggest gripe I have with Story Points. The nightmarish problems often start happening when we talk about Story Points in conjunction with Velocity.
Story Points and its evil counterpart Velocity
The moment Velocity enters the picture, that’s when discussions often start going downhill. Velocity is simply the number of completed Story Points over a period of time, such as a Sprint.
Story Points imply that more points are better. Your Sprint is like a game where scoring more points means you did a better job. A higher Velocity means you’re scoring more points, moving faster and doing better.
As I’ve said before: delivering a feature doesn’t mean you will deliver value, just like telling a joke doesn’t mean people will laugh. Focusing on delivering more features means you’re like a comedian who focuses on telling more jokes. Telling more jokes isn’t the point, getting more laughs is.
Now back to the mystical world of Story Points: what’s supposed to protect your team from pressure, can actually increase stakeholder pressure. The obfuscation of time by encapsulating your estimates in Story Points backfires precisely because the work no longer seems to have a relationship with time. Velocity becomes a magic whip to get developers to work faster and deliver more.
Imagine your whole team has 50 working days in a Sprint. Nobody will expect you to complete more than 50 ideal days. But a development team that works with Story Points and Velocity? Then suddenly, the sky is the limit.
Are you doing 50 points? Why not aim for 60 points? Why not hit 80 points by next quarter? Just work harder and make it happen! You’re not lazy, are you?
Because the relationship with time is lost in Story Points, people seem to think it’s like our universe — ever-expanding.
These are the kind of conversations you will overhear in a company obsessed over Velocity:
“Why was our velocity lower this Sprint than the last Sprint? Can you please provide a solid explanation?”
“Our velocity has stopped increasing. Maybe it’s time to hire a new Scrum Master? What’s the point in having a Scrum Master if they can’t increase our velocity?”
“We didn’t complete all stories in our Sprint. What can we do to guarantee we’ll complete them all next time?”
Companies don’t understand that Story Points still represent time and there’s no point in pushing for a higher Velocity. Like with ideal days, if your estimates are accurate, there’s a ceiling that you’re never going to cross.
How can Story Points and Velocity go back to the light side?
Even though I have witnessed countless problems and anti-patterns because of Story Points, not all hope is lost. Story Points can turn to the dark side, but they can also veer over to the light side. It depends on how you use them.
I don’t have any problems with Story Points. I know what I need to do to make them work. I make them work by following a simple rule: keep Story Points and Velocity on the team level.
When stakeholders want to know when something is done, you provide them with a forecast. Your stakeholders don’t need to know how the forecast was produced, whether with Ideal Days, Throughput, Gummi Bears, or Story Points.
If a manager wants to improve the team’s throughput, then let’s take a look at the cycle time, flow, and what’s the possible bottleneck in our workflow. Story Points and Velocity do not have to enter the equation.
The main benefit of Story Points is that they obfuscate time. The biggest downside of Story Points is that they obfuscate time. Because of the lost relationship with time, people suddenly start to believe Velocity is the one number to rule them all and that a higher Velocity is always better.
Obsessing over increasing your Velocity is like fretting over increasing your ideal days — it doesn’t make sense. The only difference between Ideal Days and Story Points is an unknown fudge factor.
The next time somebody talks about increasing the Velocity, imagine someone talking about how we should increase the number of hours in a day and throw a beaming smile their way.
When you frequently talk about Story Points and Velocity, you can safely say you have bigger things you should be worrying about instead.
great article. I agree with everything you said up until "I don’t have any problems with Story Points." I've come to despise them. Once somebody in your organization, typically a poor SM, starts advertising story points and velocity, then connects them to value I've found it's very hard to get that cat back into the bag. So then, as you stated, you try to define story points to executives and their eyes go blank. I'm convinced simple throughput is much easier to understand...if only teams could stick to creating stories that actually deliver value so a throughput metric actually meant something.