Why We Should Estimate with Story Points, Not Ideal Days?

Prediction is very difficult, especially about the future.

Niels Bohr

Estimating with Ideal Days – the Traditional Way

Every software developer has estimated tasks: “My estimate for this task is 2 days”. Usually, we do it with days, at least in my whole career so far. In Finland, we like to estimate with so-called person workdays (henkilötyöpäivä in Finnish). One person workday is 7.5 hours because that is the usual workday here. If I say two days, practically I mean 15 hours of work. Mike Cohn defines this as an ideal day in his book Agile Estimating and Planning. So we are familiar to estimate with ideal days in Finland and everyone knows what they mean.

An ideal day is not the same as elapsed or actual time. Because there isn’t ever an ideal day(s) without interruptions. We don’t code all the time. There are many interruptions during the day: emails, meetings, calls, reviews, etc. Practically ideal time is always shorter than elapsed time, and usually, it is much shorter than elapsed time. We simply do many things during the day that takes time from ideal time. Not to mention evil multi-tasking which makes the ideal day not at all ideal and takes even more actual time.

Mike Cohn mentions two benefits about estimating with ideal days compared to story points:

1. Ideal days are easier to explain outside the team and
2. Ideal days are easier to estimate at first.

But there are problems with ideal days:

• My ideal day is not your ideal day,
  • “If Mark does this, it is 5 days, but if Susan does, it is 2 days” – how should we estimate this?
• It feels too much like a commitment, not guess/estimate,
  • “Oh no! I estimated this as 2 days but I’ve worked over a week with this.”

A Scrum Book mentions that a typical workweek is much shorter than 40 hours; we use only 45 percent of our time on primary job duties. That is far away from the ideal day; why should we even bother to make estimations with ideal days?

Story Points – Relative Point-based Unitless Sizing

Story points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a two should be twice as much as a story that is assigned a one.

Mike Cohn in his book Agile Estimating and Planning

That is a simple definition of story points. It is the same as the ideal day but without unit and that one story point isn’t the same as one ideal day (even if it can be).

For example, we can estimate task A to be 2 points. And because we think task B is half the size of A, task B is estimated as 1 point. Then when we estimate task C, we think it is about the same size as task A, so we estimate task C as 2 points also. The power with story points is that they are unitless. We don’t have to care about days or hours, only size matters. This gives us more freedom and reduces pressure to do a task in one day because it was estimated as one day even if it takes longer to do.

Mike Cohn presents these benefits when using story points:

1. Story points help drive cross-functional behavior.
2. Story point estimates do not decay.
3. Story points are a pure measure of size.
4. Estimating in story points typically is faster.
5. My ideal days are not your ideal days.

So, according to Mike Cohn story points have more pros than ideal days, and story points are what he recommends. Research also shows that estimating in story points is more accurate and faster than traditional estimating in hours. Jonathan Rasmusson gives us also good benefits for estimating with story points in his book The Agile Samurai:

1. It reminds us that our estimates are guesses.
2. It is a measure of pure size (they don’t decay over time).
3. It’s fast, easy, and simple.

I especially like the first one. Too often our estimates somehow turn to commitments.

Humans are not good at estimating hours.

Rand Corporation research in the 1940’s

Are there any bad parts with story points? Of course, there are and those are the two pros mentioned earlier with the ideal days, but the opposite: story points are more difficult at first and they are difficult to explain to members outside of the team. These are valid reasons but not strong enough reasons to make story points lose against ideal days. First, we shouldn’t think just about this moment but the future in the long run. Why use ideal days even if they are faster at the beginning if story points will be faster and more accurate in the long run? And even if outsiders seem to understand ideal days easier, there is a risk that they will interpret those as actual days, says Mike Cohn.

Velocity Tells the Speed

How can we really estimate our schedule with story points? If we have 100 ideal days we can make some estimate but with 100 story points, it is impossible unless we know how long one story point will take. Velocity will tell that.

Story points don’t work alone because they are a pure measure of size, not speed. We need to know the speed; velocity. Mike Cohn describes velocity as a measure of a team’s rate of progress. For example, in the scrum, we can have a velocity in units of story points per sprint. If the team completes 20 story points per sprint, its velocity is 20. And if we have a total of 100 story points to do, we can calculate that on average it will take five sprints to get done.

How can we know the team’s velocity? One example is to look at how many story points were done in the last sprint and use that as the team’s velocity. Another technique is yesterday’s weather were velocity is the average of the story points done in the last three sprints. With velocity, we can clearly tell the estimated schedule and we don’t need any factors to change ideal days to actual days.

We can also use velocity even if we estimate with ideal days. I recommend doing it because ideal days lie about the schedule. But if we calculate velocity as ideal days done per sprint, we know the team’s velocity. That way we can estimate duration much better than only with ideal days alone.

Summary

Estimating is difficult, most of us (if not all) have failed many times when we’ve tried to estimate the schedule of the project. By separating estimations of size and speed, it will increase the results. My recommendation for estimating size is unitless story points rather than ideal days. And then use velocity to estimate speed; how many story points do team on average complete in a sprint.

Ideal days are easier to understand first and begin. Even if it is more difficult to start with story points (especially if used to ideal days), they will soon be faster to estimate and more accurate than ideal days. Researches show that we give better estimates with relative unitless sizes (story points) than with actual sizes (hours, days, etc.).

Sources

• A Scrum Book by Jeff Sutherland, James O. Coplien, and The Scrum Patterns Group
• Agile Estimating and Planning by Mike Cohn
• Story Points: Why are they better than hours? by Jeff Sutherland
• The Agile Samurai by Jonathan Rasmusson
• What are Story Points? by Mike Cohn