Content By scrum .org
Too many teams struggle with “Effort Estimation”. Too often they ask me to help them make an accurate estimate of their effort. Well, not sure this is achievable 🙂
But why is effort estimation a struggle?
Few years back I was working with a team and noticed that most of their user stories are estimated with only a few days of work whereas the actual cycle time was much longer.
When I asked them about that, they could swear that their initial estimation was correct.
It took them much longer time to get the user story to DONE because they worked on other things in parallel and had few dependencies and blockers on their way.
But after all their estimation for their work effort was accurate so everything is OK.
In another case, I worked with a large group where the senior management insisted on small user stories, no more than 4 days per story. When I joined them for a weekly status meeting, I was stunned that one manager argued with one of the participants about a user story that was estimated as 5 days of work and demanded to break it further (or estimate it shorter).
Immediately after that meeting I took a quick look in Jira. Indeed most of the user stories were estimated with up to 4 days. But what about the average cycle time? Well, this was a different story. It was around 20 days, 5 times more!! But no one glimpsed into this.
Effort estimation is not the same as cycle time.
And yet, when the customer (or anyone in the organization on behalf) asks the team about the effort estimation for a requirement, a misunderstanding is created:
The team mostly reflects the WORK EFFORT whereas the client expects to get the CYCLE TIME.
When the team says a user story is likely to be worked on for 5 days, the client hears that it will be delivered to him within approximately 5 days. If the cycle time gets much longer the client gets frustrated and angry. Why should the client care for the effort estimation if it has absolutely nothing to do with prediction for when the requirement can be delivered to him?
Some can argue that the effort estimation is not for the client, but for the team to be able to predict their velocity. But even in this case, in case there is no correlation between the work effort and the cycle time, we have a problem, Huston.
Getting back to the title of this blog – how accurate can the effort estimation be?
To my opinion, the answer would be that they cannot be accurate but should aim to be as close as possible to the cycle time. When this will happen it means that:
- The team works with minimum interrupts and context switch, hence with more FOCUS
- The team is fully accountable (and responsible) for high quality delivery
Mind the gap 🙂