Estimation is hard. Part One.

How long does it take to travel from Minneapolis to Chicago?

Give a group of ten people this question and ten answers will come back. Some may be radically different. People have a lot of trouble estimating how long something will take, or how big something is. I see this in my own life on almost a daily basis. How long will it take to change the brakes on the car? On the van? Cook dinner? Each time I think it will take a different amount of time, and each time it does – but I am still wrong about how long.

This is a problem when a business is trying to plan enhancements and future projects. The good news is that while we are bad at straight time estimation, we are usually pretty good at relative estimation. The brakes on the van will take a little longer than on the car due to the size difference of the vehicles. Dinner today will be quicker than yesterday’s because of the dishes I am making. A trip to Chicago might take twice as long as a trip to Ames, but it could be half the time as well.

The details of the last one are pretty simple. The requirements are vague. Is the trip going to be done driving, flying, or on the train? That is not our focus today though. Today our focus is on the idea of stating it will take about twice as long, or half as long, versus it will take 6 hours.

I approach estimation these days using Planning Poker. This came in part from the book Agile Estimation and Planning by Mike Cohn. (Reviewed here.) I also had been doing research online. In my research and reading I found three main ideas that really make it seem like the right way to estimate.

First is the idea of relative sizing. Instead of estimating everything in a vacuum all estimations should be made relative to each other. Knowing a requirement is about twice as big as another requirement is much more useful to the business than knowing one will take 24 hours and one will take 48. The abstract of “twice as big” makes deciding on business value much easier for the product owner. Instead of trying to decide if each requirement is worth 24 and 48 hours, she can look at the two and easily decide if the larger one is worth twice as much. No need to identify how valuable an hour is, just a relative idea of how much more business value one item provides over another.

There is a limit to the power of relative sizing. To really do a good project plan including deciding what items are optional and what items need to be done there has to be some fixed scale that will relate to time passing. This is where relative size takes on story points. A story point is a number. It stands for nothing while at the same time representing an amount of effort. For one project team a story point might stand for a day of work. For another it might stand for an hour. Still another might treat it as a week. None of the teams should think of the story point in light of that amount of time though. They should only see it as a measurement of effort. The mapping of story points to time is for planning. The only way they relate to that amount of time is via a teams velocity. Velocity in this sense no longer means the number of hours of work that gets done, but now the number of story points that gets done. Instead of a team having a two-week velocity of 392 hours (7 people at 70%) they have a velocity of 32 story points. Or 27. Or 83.

The value of story points and the velocity estimate is not in the immediate, but in the long-term trends. No matter how hard those 7 people work, how good they get at their jobs, or what they learn along the way they will always only be able to accomplish 392 hours. They might be able to accomplish twice the number of requirements, but it would not be reflected. Likewise a task that was estimated as taking 36 hours in the first two weeks of a project may only take 12 hours three months in. Using hour estimates this would need constant updates for the plan to provide the proper value to the business. Using story points there is no reason for re-estimation. That task is still twice as hard as the tasks it used to be twice as hard as. The teams greater capacity can be seen in the increased velocity of 32 story points to 47. Perhaps it goes the other way. The initial velocity estimates were aggressive, or the team lost a member that will not be replaced. Their velocity lowers from 32 to 27 but the tasks still do not need to be re-estimated.

This really leads into the last part of this that really spoke to me. The Pareto Principle. 80% of the results are achieved from 20% of the effort. Planning Poker estimates are not done on a scale of 1-10. They are usually done using a modified Fibonacci Sequence. The basic idea is that the difference in effort of an 8 and 9 point story really is not worth figuring out. The difference between a 5, 8, and 13 on the other hand can be valuable while also taking significantly less time to figure out. Knowing that a task is almost twice as hard, or not quite half again as difficult can be valuable. It is a distinction that can be discussed and agreed on without a lot of challenge. Tweaking it even further can become tedious for the team.

With this background in place Planning Poker can now move forward. In the interest of not creating more tedium that will wait until next week.