This is my post

This is my post. It's a top level element.

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.

The user story's anatomy

Unfortunately there are different meanings for the term 'user story'.

The following items are usually called 'user stories':

• A well-structured sentence like 'as a blog author I want to be able to upload images in order to impress my readers'
• A card containing a well-structured sentence (like the above), enriched with user acceptance criteria and constraints
• The above card, plus some collaboration
• All of the above and additionally an estimate and a priority (aka backlog item)

The common denominator is that the usual scheme...

As a {role} i want to {ability} [in order to {purpose}].

...is called a user story.

A user story's scope is always to define some functional requirement, in some cases bounded by non-functional constraints. This is a major weakness in all agile processes, as the non-functional requirements - which drive the architecture and the system's cost - don't get enough consideration.


A user story card is a composition of...

1. A story (functional requirement, 'as a ... i want to ... in order to ...)
2. One or more user acceptance criteria
3. One or more constraints (non-functional requirements)

Depending on the user story's degree of maturity the user acceptance criteria or the constraints can be omitted. And of course the story's maturity will be driven by it's temporal proximity to the project's current sprint.

User Stories Revisited

Today I had a very inspiring discussion with Peter Hruschka from The Atlantic Systems Guild regarding the differences between the traditional requirements engineering artifacts...

• use cases
• atomic requirements

and the agile world's ...

• user stories

Both are used to describe a system's requirements, albeit they are adressing different purposes.