The rule

• Make a good estimate of the work (in any time unit).
• Multiply that number by itself in months plus one.
• What you get is a reasonable estimate for release date (in the original time unit).

Examples

Some examples:

• Work estimated to one week will take one week.
• Work estimated to two weeks you can expect to be ready in close to a month.
• Work expected to take two months weeks will take about six months.
• Anything estimated to half a year or more won’t be finished. The scope will be changed too much before the project is finished.

While not perfectly scientific, it is actually more or less empirically derived from my own company’s history.

The steps

I tried to perform the following steps.

1. Define the scope of what you’re estimating.
2. As Mike Cohn suggests, ask each developer to make an estimate and write it down.
3. After everybody has made up their own mind, take note of all estimates.
4. Discuss the estimates if wanted, but do not revise them! (Unless someone completely misunderstood the scope.)

By writing the scores down and not revising them, developers do not get a chance to influence each other. If all of these original, uninfluenced, estimates are close to each other, you can probably be more secure with that estimate. On the other hand, if they are spread out you get an indication that risk is rather high. Estimating this way actually gives you more information, as you not only get a mean value from the estimates, but also a precision or confidence interval.

Related thoughts

Max Pool has been arguing for a similar approach, where you estimate in ranges. However, using the approach suggested above, you don’t have to set a percentage probability yourself (which might be a hard number to come up with) — you get it for free.

Furthermore, if you think about it, estimating with just a single value is almost meaningless anyway — you’ve always got a precision, that is, an interval. When you say that something will take “2 days”, what is the precision? Two days within a second? Minute? Hour? Day? Week? Also, is it an upper bound? Lower bound? Mean value? Using an interval gives you a good way of making these assumptions much more explicit.

What are your thoughts? Have you estimated using something else than a point value? Do you disagree? Let me know!

Update

In his comment below, Mike Cohn pointed out that I in fact can have my cake and eat it too. I can use the highest estimate as a “upper bound” and also continue discussing and re-estimating until everybody agrees on a single estimate. That way we get a range but do not lose the valuable discussion during the convergence.

The problem: My team had a lot of index cards which we wanted to put on a wall in order to simplify planning. We had thought about using pins, tape, magnets, and pretty much every type of device used to put a piece of paper on a wall known to man. That’s when I found it.

The solution: Flexible and adhesive magnetic tape. Just stick a piece of tape on the back of the card. Then you can post your cards on a whiteboard and move them around all day long. Up, down, left, right, left again, rearrange. If you wanna take it down and edit it, just do it and put it right back up again. So simple, so obvious. Love it!

If you happen to live in Sweden, you can pick a roll up at Clas Ohlson. In the US, I found the same product at The Magnet Source (see product C). They’re cheap too.