Not Converging on an Estimate

In his great book User Stories Applied, Mike Cohn suggests that “the goal is for the estimators to converge on a single estimate.” While discussing this with a senior product owner at a major Swedish telco (guess which one!), I came to realize that there might be a point in not converging on a single estimate when doing time estimation.

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!


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.

2 Responses

  1. Hi Henrik

    Nice blog posting. I think that teams that don’t try to achieve consensus miss a huge opportunity to discuss the work. These discussions are a huge part of the value of a technique like Planning Poker, which is how I encourage teams to do the actual estimating.

    What I’ve seen teams do that is a bit more of a hybrid is this: Drive to consensus on the estimate but then use the highest stated number for the high estimate. So, perhaps five people agree that this feature is likely to be 8 days but during the discussion one of us thought 20 days, but was talked down to 8 by making assumptions and hearing clarfications. That item would be listed with an estimate of 8 – 20.

    Other teams when they do two-point estimating will explicitly estimate the 50% likely number and then the 90% separately so there are two discussions (and consensus on each). I suspect this works better but it takes a bit longer than just using the highest mentioned number as the 90% value.


    Mike Cohn - October 27th, 2008 at 15:52
  2. [...] Mike Cohns comment on Not Converging on an Estimate: I discussed an adaption of some advice he gave in a book. However, my adaption forced me to ignore other parts of the same advice. He pointed out that there was no problem in actually doing both parts. [...] » People Who Are Smarter Than I Am - November 10th, 2008 at 08:05