Many years ago I was working as a software developer in a team with three other programmers. We once had a meeting in which our Team Leader said:
“You are late again! All of you are late! Actually, you are always late! We cannot continue like that!”
Then I replied to him:
“If all of us are late, and if we are always late, then there must be a problem in the way we do effort estimates…”
In this case, the Team Leader himself was the one doing the estimates. He did it alone, based only in his own judgment, without consulting us, the developers. When he assigned new tasks to us, it was something like:
“You now must do this task, and it must be ready in X days.”
Certainly this is not a very nice way to talk to people working with you, but the main problem here is that it is not effective. For any person, it is very difficult to do precise effort estimates. Thus, we should always avoid doing estimates alone and without asking for other opinions.
Planning Fallacy: Why Estimates Are Hard
The difficulty of people to make good effort estimates is a well-known phenomenon, and as such it was the subject of research. Scientists have called it the Planning Fallacy:
“The Planning Fallacy is 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.”
The Planning Fallacy is discussed by Daniel Kahneman, Israeli Nobel Laureate in Economics, in his book “Thinking, Fast and Slow
- “are unrealistically close to best-case scenarios”
- “could be improved by consulting the statistics of similar cases”
Psychologists have tried to explain the causes for the Planning Fallacy. Some claim that the main reason is that people have a tendency to focus on the most optimistic scenario, actually believing that this optimistic scenario is more probable than it really is. Others claim that this is just another example of wishful thinking. This means that people think about what they would like to happen, and not about what is likely to happen.
I think that in the workplace there are some other 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, it is quite clear that there should be other people participating in the estimates, and not only the manager and the worker who will perform the task. People estimating from the outside, who do not have a personal interest in the task and will not be responsible for it, can be more objective.
Planning Poker
The methodology of Agile software development has addressed the problem of poor estimates through the concept of the Planning Poker, in which all members of the team participate and contribute. Each member of the team has a set of numbered cards, with the numbers representing the effort to implement a task. For each feature in the backlog, each person makes an independent estimate using the cards. Then, the cards are simultaneously shown and people can compare and discuss their estimates.
The goal of the Planning Poker is to reach consensus, in which all participants agree with an estimate after they have discussed it and understood each other opinions. There are several reasons that cause this process to provide more accurate estimates:
- There are more people participating in the estimates, including team members that will not be directly responsible for performing the task.
- People are not influenced by others when making their original estimate, since they do that simultaneously and independently.
- People have to justify their estimates, especially if they are too low or too high.
I think this is a great approach for addressing the Planning Fallacy, and it also has the advantage of being fun and strengthening the bonds among team members.
Do you have experience with the Planning Poker? Please share your thoughts in the comments below.
Effective Software Design 
Haayim: Recently I came across Planning Falacy 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.
Thanks, Putcha, I’m glad you found it interesting.
It is important for a manager to be realistic about progress estimates, but I think many workers and managers motivate themselves by envisioning the best case scenario coming true.
‘Aim for the moon, even if you miss you will land upon the stars.’
Gabriel, please note that we are not talking about personal goals. There is always a customer waiting for the system to be delivered, and if your estimates are wrong the customer will be very frustrated…
The planning fallacy is always a good subject to discuss – mainly because it takes time for people to grasp it. The history of traditional estimates is rooted so deep, that it is not trivial to let go.
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
Thanks for your comment, Ilan. This could certainly be the subject for another post. If you already wrote about that in your blog, please share it with us.
Thank you, Hayim,
Here is a post referring to using empirical data to to continuous planning, rather than plan once up front:
Thanks, Hayim, for bringing this subject to discussion.
1. I think effort underestimation by manager as a tool to motivate employee is the worst practice ever. This is so obvious, I don’t even want to dive into explanations.
2. I think the effort underestimation is rooted in absence of adequate (and frequently basic) manager and employee training.
What I mean by that?
Most employees have theoretical understanding (if any) about their work methodology. Methodologies are Not being advocated by organizations, Not being trained, Not being acquired through practice. Most often, new employee has to learn SOME work practices from other employees through random knowledge sharing transactions. And, most often, old employees after had gone through crisis of an organization growth/restructuring, no longer contribute to that cause.
Most managers, as any employee, suffer from the same problem I descibbed above. Only with managers the situation is worth: the philological aspects of their position cause them to behave in a neutral, and sometimes, destructive ways in regards to team-level work methodology. Again, there’s too many examples of that, and to few examples of an opposite situation (when new/old manager was able to contribute to APPROPRIATE methodology definition/adoption in a team) – I won’t dive into it.
Going back to the effort estimation problem.
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?!
P.S. Now, I want to ask everybody reading my comment:
“Do you REALLY know what methodology is?” – Think! Think twice before you answer that!
“Do you have methodology at your work place?”
“Did you have methodology at any of work places?”
Pavel, thanks for your comment. I agree that the situation in most companies is very problematic regarding the adoption of a clear and well-defined methodology. I believe that having such a methodology is essential to analyze your performance over time and to learn from previous experience.
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.
One interesting characteristic of Agile is that people adopting it are frequently very enthusiastic about it. Perhaps you can doubt if Agile methods improve the productivity of software developers, but it certainly has a good effect in the motivation of the team.
I believe that this increase in motivation and satisfaction is caused by psychological factors, and I’m currently planning a research on this topic together with an expert on Behavioral Economics. I will post here more information about that in the future.
I’ve been in organizations saying “we’re gonna do Agile”, where the very word “Agile” became a curse. In untrained hands of shallow-thinking managers – that’s what it is.
@Pavel, I have worked in a variety of organizations, some of which had clear methodologies of how to do things. It didn’t help.
I prefer the word framework over methodology, indicating level of freedom, common sense, and self organization.
At the end of the day, it is the culture of the organization that dictates how things work. As Henry Ford put it: “Culture eats strategy for breakfast”
If the culture of the organization is that estimations must be provided early at all costs, then, procedures and methodology aside, managers will be put in a tight corner to provide them – at all cost.
If self organization is a value, which is based in turn on trust between teams and managers, then planning poker may prevail.
Agree.
Pingback: 使用计划扑克预防工作量估算谬误 | chainding
Pingback: Actividad #10 – SCRUM | Administración y Control de Proyectos II
Pingback: 35 Agile Development Best Practices | Effective Software Design
Pingback: Attention Agile Programmers: Project Management is not Software Engineering | Effective Software Design
Pingback: The Psychology of Agile Software Development | Effective Software Design
I have found that using story pointing (your ‘planning poker’ from above) in place of actual time estimations to be fraught with risk. For one, story pointing is not simply an estimate of time or effort. It is also an estimation of complexity, among other things.
To use it simply as a time estimator is the height of folly imo.
Mark,
I find it interesting that no one answered you. I find your comment to be prescient.
Thanks for your comments. Mark I apologize I didn’t answer before. I agree that story points should not be used as time estimates. I think that story points must be translated to time estimates, and the exact way to do that depends on several factors including the technology being used, the developer’s skills and experience and the amount of code reuse. In practice it is a number that only has meaning in the context of a specific team working on a specific project.