Should a team use story points or ideal days for estimation. Story points have clear advantages.

An ideal day is this thing that never happens. You get to work, everyone else took the day off, except when you need to ask them a question, then the needed person is immediately available and willing to help you. On this ideal day your goals are clear and so is your head. So really, there is no such thing as an ideal day except in our imagination.

A story point is a guess at how much effort something is to implement. Some storyis given an estimate of two story points and another an estimate of four. All we know from this is that the scale is linear. The easiest stories have low number, the hardest high. When we give one story a four and another a two, we are saying the four is twice as difficult, will take twice the effort, as the two.

No one really knows what a story point is. Each team has a different scale so the comparisons between groups is meaningless. Everyone can define an ideal day, but they also know there is no such thing. So why is one of these nebulous measures better than the other? It’s all in the units.

Using ideal time is a problem because of its units. As soon as time is being estimated people are much more reluctant to give an estimate, some totally freeze. Planning becomes slow and uncomfortable. No one knows enough to give a time based estimate.

The risk with ideal days is that the management focus can shift from the teams predictability to concern that idealDays != realDays. Managers will start continuous improvement teams to analyze the gap, so we can get the lost time back and turn it to productive uses. Developers have all given ideal day estimates in the past and been burned by them. So, they don’t want to give them when there are unknowns, and there are always unknowns. How much is an ideal day anyway? Rumor has it that some developers are 10X more productive than others. Whose ideal days are we using anyway, super productive Jane, or slacker Wally? These potential estimation roadblocks vanish when time is removed from the discussion.

In sizing a product backlog, points capture the relative size and scope of a story to be estimated in relation to other stories. People are much more willing to offer that one story is 3 times a difficult as another. But ask them how many days something will take, even ideal days, and people start squirming regardless of the assurances from the product owner that they won’t be held to them. I find that if teams use story points they can estimate without the worry of being held to delivering in some number of ideal days. The business goal during estimation should be that the project is being sized. This makes the estimation activity go much faster. But what good does it do to find out that some release has the size of 328 story points, when no one knows what a story point is? Good question.

Points have to be converted to time. To do this we need to know how many points a team competes per sprint, a metric known as the team velocity. Will we ever know for sure? Of course not, but we can guess and we can measure. To initially project the overall duration of a backlog, the team guesstimates (make an educated guess) the number of points it can completed per sprint. Once the team has a completed a couple/few sprints, velocity is measured, providing feedback into the planning process using the team’s story completion data. This provides important data to the group, the product owner and the product stake holders.

The feedback gives a regular measure of progress and helps the team converge on reliable estimates. The management data can give early warning of schedule problems. The effort to find the missing productivity represented by (1 – idealDay/realDay) is avoided. Everyone views the estimate for what it is, a guess of relative effort.

Predictability, no matter the unit if measure, has high business value. There are teams that can successfully use ideal time estimates, as long as no one gets hung up on the gap between ideal and real. Story point estimation avoids the whole problem.