Story Points vs. “Ideal Days”

I like to think of myself as being pretty anti-dogma when it comes to Agile methodologies. I think one of the most common ways that a team can “fail” in their adoption of Agile is to become fixated on strictly following what is and isn’t “Agile”.

One topic that has come up repeatedly for me lately is the choice between using Story Points for sizing stories in our backlog versus using “Ideal developer days”. On this topic, I have a very strong opinion, possibly bordering on “being that Agile-Nazi guy”, but I stand by it.

Background:
There are a number of ways that Scrum teams can size the items in their backlog. To be clear here, we’re talking about relative sizing – something you’d do in a release planning or backlog grooming type of meeting – as opposed to iteration planning, where you’d be tasking out a story, typically in hours. Some teams use t-shirt sizes, some teams use arbitrary “story points” (which have no units), etc. Other teams use “ideal days”. The teams I have been on lately fall into this camp. I have issues with this.

Units of time, and the associated baggage
One of the problems with sizing stories in ideal days is that we’ve become so accustomed to estimating our tasks (and being held accountable for them) in units of time, that I think we tend to slip into that typical dev mindset where we immediately switch into task estimating mode. If we’re not careful, the release planning meeting can become a tasking meeting. Related to this, though I have no evidence to back this up – I think there is a certain level of baggage that comes along with estimating in units of time. When you’ve been burned by a bad estimate, it’s easy to estimate based on the size of the ass that needs covering rather than the size of the actual story.

Mike Cohn’s “Agile Estimating and Planning” has an entire chapter dedicated to the debate over points vs. days. Cohn discusses some excellent reasons why a pure points-based approach is preferable.

Whole-team Estimates
Agile teams are often cross-functional. On my team we have, in addition to 3 developers, a QA, an interaction designer, and a visual designer. Now I’m not suggesting that the estimates won’t be driven by the developers most of the time, but there are a couple of reasons why including the rest of the team in the estimation process is helpful. First of all, it builds a more cohesive team – sizing things in “developer days” seems to imply that other people don’t have anything in particular to contribute to the process. Secondly, and potentially more importantly, you may miss out on crucial feedback from the other members of the team. A feature may be relatively easy for a developer to implement, but may take a QA a large amount of effort to properly test.

Points-based estimates don’t decay
I think this is one of the biggest reasons to go with a points based system. By saying that points-based estimates don’t decay, we are saying that for the most part, sizing estimates based on points don’t change over time. The major result of this is that your velocity will continue to be a meaningful measure of your team’s ability to deliver. It’s probably best to illustrate this by way of an example.

Suppose you have two teams that are essentially identical. Identical in size and ability. Their backlogs are also identical. Team A uses an ideal days approach to sizing their stories. Team B uses non-time-based story points.

Both teams start off their project with the same number of stories scheduled, and both teams manage to successfully deliver on their commitments.

Fast forward to a few sprints from now. Both teams have improved on their ability to deliver. Perhaps they are working with a new technology or architecture that takes some time to get fully comfortable with. Or it could be increased productivity through the use of new tools. Or perhaps it’s just a result of the team learning to work better together.

Compare the velocities of the two teams. Despite the fact that both teams have improved their ability to deliver (as measured by their velocities), Team B’s improvement is much more easy to see. The shifting of the scales of measurement for the team using ideal days makes the velocity measurement a much less useful measure.

Advertisement