Story Points or Ideal Days?

There is a long-running debate regarding the use of story points vs. ideal days for estimating backlog items, both positions supported by many good arguments. In my practice, I actually use both. Here’s how.

First of all, no matter what units you end up using, the purpose of estimations is to provide some understanding of the project’s schedule and cost based on its scope and available resources.

The best thing about story points is that they are absolutely disconnected from real-time. You can say that your team will complete 10, 50, or 100 points in the sprint, and nobody can ever blame you for coming up with wrong estimates, since a point doesn’t mean anything. What points reflect in reality are relative sizes of stories and the volume of stories the team completes per sprint.

However, every time we put together a new team, I have a hard time explaining what the heck a story point actually is.

In my experience, it is very difficult for people, regardless of whether they have come across the concept of a story point in the past, to start estimating a new product backlog by picking the smallest story and comparing it to others. I have noticed several general cases that make it hard or impractical to use points:

1. There is no consistency in size across stories; some are very granular while others are relatively high level, and there is no way to break them down further at this point in time. In this case, the team will be struggling to compare the smallest stories with the biggest ones (how much bigger are these than those? 2x, 10x, 100x?..)
2. The team does not have visibility into the complete backlog but only sees a small subset of stories to estimate, e.g. for a coming sprint. (This happens when a team is one of several working on a complex system, for example.) Relative story sizes from this small subset may not be applicable to the bigger set of stories. For example, there are only three stories in the sprint backlog: small, medium, and large. The team estimates them at 1, 2, and 5 points, but then in the next sprint, they discover stories that are XXXS and XXXL. How many points they should assign to them now?
3. An opposite situation takes place when the backlog is very big, let’s say 200 or more stories. Finding the smallest story could be tricky, but it would be trickier to compare it to the other 199 to assign correct numbers of points to each.

When confronted with these kinds of cases, teams often feel that a point-driven approach is inadequate. I have found it useful to introduce the concept of absolute ideal days in order to enforce structure estimation practices. This is how I use it. 

At the release planning phase, when we are required by the customer to provide a high-level estimate for the entire backlog, I ask the team to assume that one story point is one ideal day. This means that a story estimated at 1 point can be done (designed, developed, and tested) in one day, assuming no distractions or breaks. This helps me build some measurement scales for the team. 

I use additional techniques like  Fibonacci rows to avoid micro-estimating (trying to breakdown stories into tasks to estimate them) and planning poker to level out different team members’ knowledge and skills. Ultimately, with complete estimates of the backlog in hand, I can add up the ideal days to assess the schedule and cost. Even without knowing the team’s past performance, we can usually come up with some kind of load factor for the team (to borrow a term from extreme programming) using risk and contingency considerations.

However, we don’t use ideal days for the entire life of the project. Once the project is committed, I simply don’t need the tie to real time anymore. 

After work gets underway, the only two things under our control are:

1. Team velocity 
2. Scope. 

To track velocity, we can easily use the number of points the team completes per sprint. 

The scope can change significantly over the course of the project, affecting schedule and cost. If the initial project commitment was 100 story points, then adding, say, 30 more points’ worth of work will likely have a costly impact.

If both the schedule and the costs are kept to their original levels, I will need to replace a bunch of original stories of the same size. 

Alternatively, if the customer is flexible about budget and timeline, we can add the appropriate number of iterations to implement the new stories, and that can also be done with points, with no need to revert to ideal days. 

The team will get into it once they get going, usually after 3 to 5 sprints, as they learn how to compare stories with each other, identify the smallest reference stories and break up bigger ones before estimating them.

So to sum up, I do believe that story points work; I just don’t believe they work equally well for all teams and situations. Sometimes you need to come up with a ‘hack’ to kick off the estimation process.