How many times have you started on a project and, in the very first estimation meeting, had no idea what to say? Have you ever asked not to participate in that meeting because you did not feel prepared?
This happens more often than it seems. When we estimate, we face a big dilemma: a commitment surrounded by uncertainty. Estimation is not meant to police people, but to give visibility into the effort a task might require so product planning can improve.
Estimates often create a false sense of control. Labelling a task gives an impression of security and commitment, but that impression is often a fallacy. An estimate is not a date; it is an indicator, and one that can change. The less precise the estimate, the weaker that feeling of certainty becomes.
Still, the information produced in an estimation session is very valuable, even if it is not absolute truth. The question is: how should we run those sessions?
Build reference points
- “This is a one.”
- “Well, to me it feels like a five.”
This kind of exchange is very common in estimation sessions. What is the problem? Once again, bias. At Agile Open Spain 2022, Fernando Bogas Pomares proposed the following exercise:
Without looking it up online, how tall do you think the Eiffel Tower is?
Your answer may be closer or farther from reality, but once everyone shares their estimate, the spread between answers is usually huge.
Now imagine you compare a picture of the Eiffel Tower with a picture of the Great Pyramid of Giza, and you know the pyramid is 139m tall. How tall would you say the Eiffel Tower is now?
At that point, most people get closer because they finally have a reference point.
And if we add even more information? We can also compare it with the Empire State Building, which is 449m tall:
With these references in place, it becomes easier to estimate the height of the Eiffel Tower with more precision.
💡 As an extra note, the Eiffel Tower is 324m tall. Were you close?
The key is to have reference points. When a team estimates, it needs to agree on what a 1, a 3, a 7, an S, or an M actually means, or whatever naming system the team prefers.
The work starts before the estimation session itself: define what each label means for the whole team. For example: a UI authentication form is a 1, a REST API without business logic but with database persistence is a 3, and a task that spans from UI to database, including documentation and regression testing, is a 7.
The more real those examples are, the better. It helps to use specific tasks that have already been completed in the project.
Once those labels are defined, it is important to revisit them over time. Application complexity can grow, working methods can change, requirements can evolve, and technical debt may remain unresolved.
It is also worth remembering that these are team labels, for the team. As soon as team composition changes, it makes sense to redefine the system.
Keeping these references documented is a very good idea because it makes it easier to revisit them and track how they evolve.
⚠️ It is not advisable to have more than 3 labels.
Group consensus
So far we have talked about labels, estimation, and values from an individual point of view. But in the end, this is team work. Quite often, more weight is given to the opinion of an expert than to the group as a whole.
Expertise is certainly a useful reference point, but it is not absolute truth. There is an experiment by Francis Galton that illustrates this perfectly.
In a town, two groups were formed: the first included only the town butcher, while the second consisted of the rest of the town. When people were asked to guess the weight of a piece of meat by sight, which group do you think was more accurate?
Surprisingly, even though the butcher’s answers were not far from reality, the town as a whole was often more precise. That comes from the collective factor: discussion, shared reasoning, and contrast. The butcher relied on experience, but had no chance to compare or debate, while the second group did.
Of course, external factors can affect the group too, such as the classic outlier who introduces wild estimates. Even so, in daily work we should remember that this is still an estimate, not a number carved in stone with zero tolerance for deviation.
Conclusion
First of all, thanks to Fernando Bogas Pomares for taking part in Agile Open Spain and sharing his Agile Coach perspective with the attendees. Thanks to that workshop example, we were able to define a few basic rules for labelling tasks, aligned by the team and revisited over time, which help improve precision in daily work.
On top of that, learning how to debate and reach consensus without treating expert opinion as unquestionable truth helps people feel more involved in everyday processes.