Introduction

To estimate the length of time it will take to complete a project, we first break a project down into its components and then estimate the size of each component relative to the others. In estimating the relative size of project components, the first step is to identify the smallest component. The development team will then assign project points [1] to every other component based on its size relative to the smallest component.

Project Points

Project points are a means of estimating the size of a project. The smallest project component is assigned a project point value of one. Components assigned two project points are estimated to be roughly twice as much work as the smallest component. Likewise a two-point component should be roughly two-thirds of a three point component. To ensure a more thoughtful approach to estimating project points, we draw project point values from the following sequence of five numbers:

1, 2, 3, 5, and 8

All components must be assigned one of these numbers as its project point value.

Velocity

Estimating project size provides us with a means of deriving the duration for a project. If the total number of project points for all components of a project is 100, we can derive the duration of the project by estimating the number of project points the team can complete each week. If that number is 10, the project is estimated to take 10 weeks to complete.

The rate at which a team completes project points is its velocity. We calculate the velocity of a team by summing the project points of each component a team completes in a given iteration. The project points for uncompleted or partially completed components are not counted. By tracing velocity, we can refine our estimates along the way. For a 100 point project, if we initially estimate that the team can complete 10 project points per week, but find that after three weeks, the team averages eight project points per week, we can revise our project duration estimate from 10 to 12.5 weeks.

Using Velocity to Manage Effective Customer Contact

For many projects, estimating project duration is important, but perhaps less so than accurately providing short-term estimates on the amount of work the team can accomplish in the next iteration or two. In our development process, it is essential to be able to gauge when the next release can be made available for customer review. A measure of velocity permits the team to determine with a sufficient level of accuracy which project components they will be able to complete in the next iteration and, therefore, to plan the next customer engagement accordingly.

Planning Poker

The development team estimates project points by achieving consensus on a single value for each component [3]. The team does NOT assign multiple point values, each of which depends upon who will complete the work. Instead, the team works to identify a reasonable project point value regardless of who is eventually tasked with a given component.

The strategy the team uses is called Planning Poker [1]. Participants in planning poker include all developers on the team. The goal in estimating each component is a good approximation that can be arrived at cheaply. In order to estimate component sizes using planning poker, proceed through the following sequence of steps.

1. Each estimator is given a deck of cards. Each card has written on it one of the valid project point estimates. The cards should be prepared prior to the planning poker meeting. The numbers should be large enough to see across a table.

2. For each user story or theme to be estimated, a moderator reads the description.

3. The product owner answers any questions that the estimators have.

4. After all questions are answered, each estimator selects a card representing his or her estimate.

5. All cards are simultaneously turned over and shown so that all participants can see each estimate.

6. If estimates differ, the high and low estimators explain their estimates. A constructive conversation here is extremely valuable in arriving at an accurate estimate.

7. After the discussion, each estimator re-estimates by selecting a card. In many cases, the estimates will already converge by the second round.

When to Play Planning Poker

1. Always at the beginning of a project.

2. Usually for the first three iterations or until the team feels comfortable with their estimates for project components.

3. If at any point in a project, estimates seem to be systematically inaccurate. If such a situation arises, it is necessary for the team to revisit its estimates and the rationale underlying those estimates.

References

1. Agile Estimating and Planning. Mike Cohn. Prentice Hall, 2005.
2. http://en.wikipedia.org/wiki/Fibonacci_number
3. Notes from Agile Estimating and Planning by Mike Cohn.