Making The Case for Replacing Story Points With Ideal Days

Stop Being Bullied with Story Points and Velocity

Story Points started out as Ideal Days multiplied by three. In the words of Story Point inventor Ron Jeffries:

“In XP, stories were originally estimated in time: the time it would take to implement the story. We quickly went to what we called “Ideal Days”, which was informally described as how long it would take a pair to do it if the bastards would just leave you alone. 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.” - Ron Jeffries, Story Points Revisited

Besides not leaving you alone, ‘the bastards’ didn’t understand the concept of Ideal Days either:

“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.” - Ron Jeffries, Story Points Revisited

To fix this, they started calling their ‘Ideal Days’ just ‘Points’. Problem solved, right?

Wrong.

That’s where all the problems started. We replaced a slight problem with a string of bigger and worse problems.

Concealing Time With Story Points

Stakeholders not understanding Ideal Days is a much easier problem to solve than explaining something as intangible and complex as Story Points. Case in point, if you ask ten people to explain Story Points, you will get many different explanations. Plus, based on experience, most of them will be completely wrong.

That’s why I vehemently believe that if your stakeholders are unable to understand Ideal Days, you can forget about them ever understanding Story Points.

And herein lies precisely the problem. Story Points are abused and misused because few people, most Agile Practitioners included, understand them. Especially if you include the concept of Velocity. They were invented to solve a specific problem and introduced many other issues.

If I got a dollar for every time I heard someone say that Story Points are purely about complexity, I’d be a millionaire!

The biggest strength of Story Points is they conceal time, which is also the biggest weakness of Story Points: they conceal time. What happens by obfuscating time?

• For team members, it becomes harder to judge whether something is on track, or off track. Nobody knows what 8 Story Points means, besides that it’s a size that usually fits in a Sprint.

• Stakeholders lose the notion of time, as the purpose of Story Points is to hide estimated completion time.

• Instead of talking about time, we begin talking about points, and more points are always better. By concealing time, with Story Points, the sky becomes the limit: more points are always better.

• We open up the potential rabbit hole of management trying to compare teams' productivity based on fuzzy Story Points that can’t really be compared between teams.

• Now, we suddenly begin talking about Velocity and why teams should work to increase their Story Points, usually indefinitely.

In short, by discussing Story Points, we enter the fairy tale land of points, where time stops mattering and the only thing that matters is completing more points.

We can visualize the messy state of affairs as follows:

With all this talk about points, we are entirely missing the point. We replaced the simple explanation of why 5 ideal days is not equal to 5 days of work with the much more complicated explanation of why our Velocity isn’t 50 Story Points every Sprint or why it isn’t increasing indefinitely.

We replaced a simple question with a whole host of other, more difficult questions to answer that rarely get resolved.

What if we used Ideal Days instead of introducing Story Points?

What do you think would happen? Well, I definitely believe these questions are far easier to answer:

Let’s be honest: these questions sound pretty silly when you’re talking about Ideal Days instead of Story Points.

That’s another benefit of using Ideal Days: you’re much less likely to have these wasteful conversations about Velocity and Story Point completion rate, and you’re also much likely to talk about the root causes why you don’t have enough time to do work.

Ditching Story Points and Bringing Back Time in the Mix

Story Points do represent time. We don’t know how much exactly, because that’s the point of Story Points, they were invented to conceal time, but I do believe we’ve two things of value along the way: the notion of time and the fact our estimates will turn out to be wrong.

Uncertainty, risk, and complexity all influence story points, but each one alone does not determine the effort it takes to complete a story-pointed piece of work.

These same factors will also affect your Ideal Days, but there’s one big difference: everybody immediately understands we’re talking about time. We’re not talking about points, something fuzzy, mushy, intangible, and dimensionless, where everybody has a wholly different perspective of what it means.

Some teams go one step further than using estimates and decide to apply right-sizing or #NoEstimates. This means you try to slice work as small as possible to reduce uncertainty, risk, and complexity. You don’t even waste time estimating, as it’s likely to be wrong anyway. Instead, you focus on slicing the work as small as possible.

The biggest problem with going from Story Points to not using any estimates is that it is a bridge too far for many people, which I understand entirely. Going from estimating to not estimating sounds pretty scary, and your stakeholders will believe you’re losing something important along the way.

With #NoEstimates and right-sizing you’re still estimating, but you limit it to just two options:

1. We’ve sliced it sufficiently small enough to begin working on it

2. We haven’t sliced it small enough to begin work

You can still forecast how long you expect it to take based on historical data, which is more accurate than our opinions and guesses based on Story Point estimates and velocity. You just need to know how to perform that kind of forecasting.

Nick Brown

‘s article on Escaping Story Points with Right Sizing is an excellent place to start.

At the end of the day, it doesn’t really matter if you use Ideal Days, Story Points, Right-Sizing, or #NoEstimates, as long as you don’t go down the rabbit hole of trying to improve your predictability beyond the point it can be improved and there is no expectation to keep on improving your productivity indefinitely.

Remember, the more we try to prevent sucking at predicting, the more we will guarantee to suck at adapting. The more we try to predict and nail our guesses, the more noise will enter our plans and minds, and the busier we will be over-fitting our plans and actions and making them worse.

Story Points were invented to prevent being bullied with time, but the opposite happened: teams are bullied even more.

The next time you’re being bullied with Story Points and Velocity, consider trying out Ideal Days. There are far fewer ways for your stakeholders to bully you around with Ideal Days than with the magical whip of ever-increasing Velocity and Story Points.