Saturday, September 24th, 2016
Suppose that a user story is estimated in three days (Ideal Engineering Days) for an archetypal Experienced Senior Programmer. Assume that 100 different Experienced Senior Programmers each program this story. How long would it take each to complete it? The next table shows the expected result:
In that table, we can see that if we use two days as our estimate, we’re giving an estimate that will hold true for less than 50% of the cases. We don’t get 50% until sometime the third day.
We can see the same information in the following curve: the X-axis represents the time it takes to complete the work and the Y-axis represents the probability of completing the task at a certain time. This curve represents all the variation that could occur and will impact the task completion time.
The curve takes on this general shape because there is normally not much that can be done to accelerate the completion of a task but there are an infinite number of things that can go wrong and delay the completion of a task.
The task cannot be completed before a minimum amount of time. At a certain point it is an “Aggressive but possible time” at which the task could be completed. The curve then tapers off and theoretically does not reach a zero time since there may be times when a task may not be completed. However, somewhere after the “Aggressive but possible” time is an estimate that we provide for tasks. This is marked as “Highly Probable” in the graph.
Summing-up: So how confident should we be in each estimate? Clearly, we don’t want to give estimates we can be 100% sure of. Both 50% and 90% estimates convey extremely useful information and we should estimate at both levels of confidence.
These notes have been taken from:
- The post On estimating project tasks.
- The book User Stories Applied: For Agile Software Development , by Mike Cohn.