In his recent blog posting “Planning Poker: Avoiding Fallacies in Effort Estimates” Hayim Makabee discusses a common problem of effort estimation called planning fallacy and why planning poker helps to avoid it.
Effort estimation might be one of the most challenging activities in software development for managers and engineers. One common problem in this context is effort underestimation caused by planning fallacy. Wikipedia defines planning fallacy as
a tendency for people and organizations to underestimate how long they will need to complete a task, even when they have experience of similar tasks over-running.
To illustrate possible characteristics of this problem, Makabee quotes Daniel Kahnemann, nobel laureate and author of “Thinking, Fast and Slow”. Many plans and and forecasts are unrealistically close to best-case scenarios, and they could be improved by checking the statistics of similar scenarios.
Makabee thinks that in software engineering there might be two major reasons for the planning fallacy:
- If the manager is the one doing the estimates, he has an interest to make them hard to achieve, in order to push people to work more productively. Managers always want to see the work completed as fast as possible.
- If the worker is the one doing the estimates, he will be ashamed to assign too much time to himself. People are afraid of doing pessimistic estimates for their own tasks, because they may appear to be lazy or inefficient.
Thus, additional people should participate in the planning who do not have a personal interest in the task.
This is why, according to the author, the Scrum planning poker is helpful. It enforces independent and consensus-oriented effort estimation by multiple participants. In the planning poker each participant gets a set of cards with numbers and chooses one of the cards to estimate the effort for a specific task. The cards are "simultaneously shown and people can compare and discuss their estimates". Makabee proposes to leverage planning poker in order to avoid the planning fallacy, because many people are estimating in the planning poker including those not responsible for the task. In addition, participants make their own independent estimates and need to explain their estimates, especially when they are very low or high.
A couple of readers commented to the article.
Putcha V. Narasimham thinks, the planning poker is really helpful:
Recently I came across Planning Fallacy but I did not know that Agile has a remedy for it through Planning Poker. In deed it is a great and practical trick. A rare sensible thing I have seen in Agile Method.
Kirschilan adds:
In addition to all said above, it should be noted that estimating using planning poker is one aspect of this. Another is using real empirical data to fit scope to the plan. In agile this concept is called velocity.
The idea is that, assuming our estimation model is rather stable, regardless of optimism, we can use these numbers to figure out how much did we really fit in in previous periods, in order to plan the upcoming one.
Using these data over time helps the team “consult the statistics of similar cases” in their own recent history.Here is a post referring to using empirical data to to continuous planning, rather than plan once up front:
http://fostnope.com/2012/05/14/what-does-a-butterfly-say-at-the-end-of-the-day/
Another reader, Pavel Bekkerman believes that effort underestimation by managers is the worst practice ever, caused by absence of adequate training. In addition, he says:
In absence of methodology we have individuals and teams largerly desynchronized in their work and not aligned with master plans. We have managers struggling to find their place in a chaos, and not providing any impact. And now the bottom-line question:
Do you REALLY think that with such a legacy, it is possible to expect anybody to learn from previous experience and provide adequate estimates on any task longer than 1-2 workdays?
… to which Makabee responds
[…] However, I do think that some companies are in much better shape than others. In particular, I’ve seen how the adoption of Agile methods has improved the situation in practice. [...]