SCRUM estimation accuracy

Question

I would guess that there are a lot of cases where the estimation turns out to be wrong at some point. Because as soon as you drill down into the nitty gritty details of a backlog item you will probably almost always find something that you haven't thought about during planning. This can happen either during task level sprint estimation or during the actual sprint.

During task-level estimation you might discover so many tasks for a story/backlog item so that the initial estimation needs to be adjusted. What do you do now? Do you go back to the product owner and tell him that he might want to re-prioritize its backlog items, now that takes much longer (or even less)? Basically it could mean that the whole team needs to go back to story-level estimation and reshuffle the stories?

During the sprint you might discover that the implementation needs much more effort than initially thought. What do you do now? Do you silently continue the sprint knowing that you can't finish it as planned? And from now on you will add a "security buffer" to all estimation?

Generally, how does SCRUM address estimation accuracy as a whole?

If I understood it right, the SCRUM developer team kind of "promises" the product owner that it will deliver as planned. But that can only be done if they estimated accurately. So estimation seems to be very crucial to the success of SCRUM but also very hard.

Answer 1

Generally, how does SCRUM address estimation accuracy as a whole?

By adjusting on-the-fly. You assign story points as a measure of size and complexity. You try your level best to assign points on a like-for-like basis between tasks of comparable size and complexity.

You inevitably get it wrong for the first few sprints. As time goes on, you adjust future estimates by the revealed "velocity" of the overall project.

The concept is that you create a feedback loop to calibrate the value of story points for that sprint, and that you accept uncertainty. A good discussion is found in Mike Cohn's book, Agile Estimating and Planning.

Because as soon as you drill down into the nitty gritty details of a backlog item you will probably almost always find something that you haven't thought about during planning.

Missed tasks in estimate is the second most common source of estimation error in development projects (the 1st is ... changing requirements!)[1]. It's also a possible root cause of the "Planning Fallacy" generally. Agile processes tend to be against decomposing tasks too far in advance.

However, the usual way to manage this risk is to build up estimation checklists. McConnell's Software Estimation: Demystifying the Black Art is a good resource -- tables 4.2, 4.3 and 4.4 (pp. 44-45) are an excellent starting point for your own checklists.

[1] van Genuchten, Michiel. "Why is Software So Late? An Empirical Study of Reasons for Delay in Software Development". IEEE Transactions on Software Engineering, June 1991.

Answer 2

Estimation process is the hardest thing in SCRUM. Sometime it may take up to 1 day to sit in conference room with a team and discussing what efforts need to be applied in order to complete every particular story. Don't even hope to get an accurate estimate in few first sprints. You should just accept this as the fact and go forward. Depending on how much details in your stories and how long team work together this process will be getting better from sprint to sprint and estimate will be more accurate. So far you can just calculate velocity or take 0.5 as the current velocity of you team. After you end up with first sprint you will get a more accurate velocity which then can be used to build a scope for next sprint.

My team had a huge problems with giving an accurate estimate at the very beginning of a project. There was nothing in a project we could rely on, there was no architecture and the system is so large and complicated so everybody was scared to give any estimate at all because nobody knew what exactly should be built. We've solved this problem by introducing System Analyst(SA) to our company who is analyzing all incoming requests and doesn't pass them to development until everything from business point of view will be clear. The main purpose of SA is to understand new feature, see how it can be implemented and propose the solution on high level taking in account dependencies on already implemented functionality and keeping in mind the functionality we plan to implement in upcoming sprints. After initial analyzing has been done SA creates stories and add them to backlog. Then these stories go to designers. They design screens and attaches them to stories. After that story goes to product owner for approval and setting business value.

All of these steps above has significantly reduced a time spent by whole team on estimation meetings. Now when meeting starts we have almost everything we need. Every story is explained in details, developers see how it affects existing functionality and see design so it's easy now to focus on technical questions only. So just as an conclusion in process we built SA and Designers are working on features which are planned for next sprints while developers and QA are focused on the active one. This allows us by the end of active sprint to get all stories analyzed and with design for the next one.

Answer 3

The simple truth is that estimation accuracy is a contradiction in terms. Like unicorns, it simply doesn't exist. By definition, an estimate is not accurate.

With that in mind, Scrum and other agile methodologies try to work around that limitation, as opposed to beating down windmills. In Scrum, an a priori estimate of the complexity of Product Backlog Items (user stories, requirements, etc.) is made to give the product owner a rough idea of how many stories he can expect to be completed in the upcoming sprint. After breaking down the PBIs into tasks, each task is estimated according to the time they believe it will take to complete. Once the team's capacity is met, they have a (slightly) better estimate of what they can deliver by the end of the sprint.

These estimates are still not accurate.

The way an agile product owner deals with this inaccuracy is by reducing the cost of delay in delivering the product. The PO defines and prioritizes his stories in such a way that he delivers the most important part of the product as early as possible, and creates a (still incomplete) usable and valuable product as early as possible. This way, whatever is not done on time (end of sprint or release date) is still the best product that could have been delivered, and often a good enough release can be created before time, with the rest, the least important features delivered in small batches, soon after.

That is how Scrum deals with estimates' (in)accuracy.

Answer 4

Scrum handles estimation wonderfully and easily. You said "As a whole" but you are talking about one single sprint. You are talking about the promise made on one single sprint. Imagine: The promise made on first sprint failed, promise made on second sprint failed. Now what would happen to the third sprint? On what basis will you make the promise for the third sprint? Answer to your question is this basis

What if your promise in the first sprint came true? Then you were just lucky! In short, your estimation skills are not needed in scrum. No one asked you to promise/commit. You were never given enough time to estimate anyways, so why bother? :)

In waterfall it is exactly the opposite though. You are given time, you promise, you are responsible and you move earth to keep the promise.