In this post I’m going to show you the process and techniques to effectively estimate user stories.

Scenario

In our project we are using an iterative process in conjunction with user stories and we need, or are asked, to provide an estimate of how long the project will take.

Ideal Estimation

The best approach for estimating user stories would be one that:

• Allows us to change our mind whenever we have new information about a
  story
• Works for both big and small stories
• Doesn’t take a lot of time
• Provides useful information about our progress and the work remaining
• Is tolerant of imprecision in the estimates

Story Points

An approach that satisfies each of these goals is to estimate in Story Points.

Story Points are relative estimates of the complexity, effort or duration of a story.

A nice feature of story points is that each team defines them as they see fit.
Story points can be entirely nebulous units or ideal time units like “ideal day” or”ideal week”.
Of course, as we’ll eventually need to convert estimates into time, starting with ideal time makes that conversion a little simpler than starting with an entirely nebulous unit.

What to Include

When programmers estimate a story, they should include everything they’ll need to do to complete it.

They need to factor in such things as testing their code, talking to the customer, perhaps helping the customer plan or automate acceptance tests, and so on.

Estimate as a Team

Story estimates need to be owned collectively by the team for two main reasons:

1. Since the team doesn’t yet know who will work on a story, ownership of the story cannot be more precisely assigned than to the team collectively
2. Estimates derived by the team, rather than a single individual, are probably more useful and accurate

Process

To estimate user stories as a team:

1. Implement a baseline story
2. Compare with the baseline story and other user stories
3. Split in tasks

From Story Points to Expected Duration

Now we need a way to convert story points into a predicted duration for the project.
How to do that?

The answer is to use team velocity.

Velocity represents the amount of work that gets done by the team in an iteration

Once we know a team’s velocity, we can use it to turn ideal days into calendar days.
For example, if we estimate our project at 100 ideal days, then with a velocity of 25 we can estimate that it will take 100 / 25 = 4 iterations to complete the project.

It is often necessary to estimate a team’s initial velocity.
To do that you can:

• Use historical values
• Run an initial iteration and use the velocity of that iteration
• Take a guess

References

Mike Cohn