Regardless of what method you use or what “Agile” methodology or implementation you subscribe to … you probably estimate tasks as a team in some way.
Sometimes, particuarly if things are dragging on a bit, people can become really frustrated with the estimation process. I find this to be especially true when using a non-linear scale for task estimation.
Digging into the root of the frustration there’s a lot of red herrings. People often find the scale vague or don’t have a shared understanding of why a non-linear scale is chosen. Even in a “traffic light” system of estimation where the method is simple frustrations can still bubble up.
I think the real root of frustrations, especially those aimed at the method of estimation rather than the reason come from a misunderstanding about where value is derived from in estimation.
It isn’t all about the numbers. It isn’t all about gaining an accurate picture of required effort, complexity or comittment.
A big chunk of value is gained from:
- Discussion of the task’s scope as a team
- Giving everyone, as stakeholders in the task, the opportunity to voice risks and concerns
- Ensuring that everyone is aware of work (together with backlog maintenance)
- Gaining concensus about the nature of the task
- Ensuring dependencies are properly discussed
- Ensuring the task is well specified, clearly written and understood by all
I find that even where these valuable side-effects are also apparent in other parts of the development process, estimation concentrates them.
Even if estimation sessions are unhealthy and produce inconsistent estimates that don’t model the real world, you’re still gaining secondary benefits by continuing. That isn’t to say a deficient estimation process is acceptable; but it isn’t all about the numbers.