In a project that uses agile development, a team will need to estimate the work involved in a number of user stories that they intend to work on within a given timebox (or sprint).
The team will involve people with different estimating styles, different levels of experience and different technical skills. To reduce the spread of estimates and enable everyone to contribute to the estimating process the first principle of planning poker is to estimate in ‘story points’ rather than hours or days.
A story point is a relative measure of size and complexity (hence the link to comparative estimating). The team will start off by selecting a relative simple story and assigning a value of 1.
A common example used is that of painting a wall. This is a relatively simple job and would be assigned a value of 1 – this is the baseline story. A novice painter and an expert decorator may take very different amounts of time to paint the wall but they would agree that it is a simple, straightforward job. They would also agree that painting two walls would be 2 story points. They may also agree that painting all four walls in a room would be only three story points because of the economies of scale.
To continue with the decorating example, the team may also have to consider painting a window. This requires more preparation and careful masking of the glass. It is more complex than painting a wall and so may be given a story point value of 2.
The process now needs to garner opinions from all the team members without bias. This is where the ‘poker’ cards are used in a way that has similarities to the Delphi process.
Team members are given a set of playing cards that have values loosely based on the Fibonacci sequence (1, 1, 2, 3, 5, 8, 13…….). The reason that these cards are not a linear progression (1, 2, 3, 4, 5) is that the larger and more complex a task is, the more difficult it is to estimate accurately.
The ‘infinity’ card may be used to indicate that the estimator does not think the task can be completed and the ‘?’ is used if the individual is unable to provide an estimate.
The process starts with everyone studying a user story (e.g. painting a window) and having a brief discussion about what this involves. They then privately assign a story point value (by comparison with the baseline story). It is important that there is no conferring at this stage. Everyone is then asked to reveal their estimate by placing a card on the table simultaneously. This avoids the discussion being overly influenced by the first estimate (a concept known as ‘anchoring’ where people adjust their opinion based on someone else’s opinion).
If all the estimates are within one step on the scale (e.g. all 3s and 5s or all 5s and 8s) then the story is assigned the higher value. If the range of estimates is greater than typically the facilitator will ask someone with a low estimate and someone with a high estimate to explain their reasoning.
It may be, for example, that the user story wasn’t precise about the type of window and different estimators made different assumptions about the complexity of the window based on their recent experience.
The estimate range may then be narrowed by clarifying the story (access to the originating user is necessary here) or reaching a common understanding about the complexity of the task amongst the team and repeating the process.
Each team that develops user stories within a timebox, will have a ‘velocity’. This is the number of story points that they typically complete within a given period (e.g. 2 weeks). Calculating velocity clearly needs some sort of conversion from story points to time (in hours or working days). Velocity is an inherent quality of a team and at the start of the delivery phase of a project this is, in itself, an estimate. As more timeboxes are completed the greater certainty there will be about a team’s velocity. This then enables higher level planning to be done by the project management team based on the story point estimate done by the delivery teams.
Planning Poker® is a trademark of Mountain Goat Software