Agile 101 – Estimating Work with Story Points

Agile 101 – Estimating Work with Story Points

In each iteration, Agile project teams  implement a set of user stories pulled from the product Backlog in priority order. These stories make up the iteration backlog. The number of stories implemented in each iteration depends on the amount of effort it takes to fully implement each story, as well as the capacity of the team.

The question – how do Agile teams estimate the size of each user story? Although estimating by effort hours is very common in traditional projects, it is actually not used very often on Agile projects. A more common approach is to use a technique called “story points”. Story points are an abstract method of estimating the relative complexity of implementing a user story.

Each project team can establish their own story point scale. For example, let’s say user story A is estimated to be 5 story points (whatever this means). If the team thinks user story B will take twice as many hours to implement, the team would assign 10 story points to user story B. There is nothing magical about the use of 5 story points or 10. Another team might scale these same two user stories at 25 and 50 story points respectively. Even though the numbers are different, the key is that the story points represent relative sizing of the user stories. In both examples user story B will take twice as much effort to implement as user story A.

Once the relative size of a story point is set for an Agile team, the team can estimate how many story points they can deliver in an iteration. Again this is relative based on the scaling process used for the story points themselves. Using the above example, the team that estimated stories A and B to be 5 and 10 story points might be able to implement 45 story points in an iteration. On the other hand the team that estimated those two stories at 25 and 50 story points might be able to implement 225 story points in an iteration.

The general characteristics of story points include:

• Story points represent the work required to fully implement a user story.
• The stories are estimated independently by team members and then the team collaborates toward a consensus opinion.
• If a user story is too large to be implemented in one iteration it needs to be broken down into two or more smaller stories that can fit within an iteration.
• Many of the estimating models are designed as games that are interesting and engaging for the project team. This includes planning poker and animal points.

Over the course of a few iterations the Agile team quickly understands how many story points can be completely implemented in one iteration. This is known as the team “velocity”.

Summary

Agile projects have a number of unique techniques that are not easily transferable to traditional waterfall projects. One of these techniques is the estimation of user stories using abstract story points, and the use of story points to determine how much work can be completed in an iteration (velocity). These are simple yet very effective techniques that are the hallmark of an Agile project.