...
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 principle objective is to identify the smallest component. The development team will then assign project points 1 to each component based on its size relative to the smallest component.
Project Points
Project points are a means of estimating the size of a project so that we can estimate its duration. The smallest project component is assigned a project point value of one. Components assigned two project points 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:
...
All components must be assigned one of these numbers as its project point value.
Velocity
Estimating project size based on project points 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.
...
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 for components by assigning a single value to each component through discussion that reaches consensus 3. The strategy the team uses is called Planning Poker 1.
...
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.
...
3. If at some point further on in a project estimates seem to be systematically inaccurate, 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. Shannon Bradshaw. https://uknow.drew.edu/confluence/pages/editpage.action?pageId=9604256