Dienstag, 4. Oktober 2011

Estimation in Scrum - Eliminating the Productivity Estimate

Scrum's measure for functionality - the story point - is an often discussed and rarely understood, but crucial part of Scrum.

Even most Scrum books don't describe it properly. However, it's quite easy to understand the concept behind it once you consider the problems of classic effort estimation.

effort_in_person_days = work / productivity
work = complexity x amount

So effort can be seen as...

effort_in_person_days = (complexity x amount) / productivity

Considering that productivity varies by the factor 10 (!) between individual developers it's quite clear that estimating effort requires one of the two prerequisites:
  • we assume to assign the work to a 'standard developer' with a 'standard productivity' and accept the huge spread, hoping that the bias will be compensated by a large number of work packages and team members. Sometimes this might work out.
  • we add a 'risk buffer' to our estimations to compensate for the bias. This will in virtually all cases lead to goldplating, as no matter how long the planned work will be, the team will fill it up with work and produce a more sophisticated solution. Unfortunately not at reasonable cost.
Scrum on the other hand uses a different approach and eliminates the inherent bias that is induced by the large spread in productivity. Simply said productivity is left out from estimation.

size_is_story_points = complexity x amount

Notice that this is the same formula that was used for effort, but without the productivity component.

But finally it's about cramming the right number of user stories into a sprint, right ? So the budget (the team) and the duration (sprint length) are fixed. Somehow there must be a relationship between the size and the effort. And the missing link is the productivity.

But the real deal with Scrum is that productivity is not estimated but measured. The productivity measure of choice is the team's past performance, the velocity.

So to summarise estimating in Scrum, you estimate the same thing as in traditional effort estimation, but you leave out the very inaccurate productivity-estimate from your calculation and use the measured velocity as a better substitute.