One pitfall of Planning Poker resides in making 'convergence to consensus estimate' an obligation rather than a natural result of the conversation that follows a round of play. Doing so runs the risk of erasing useful information, i.e. The degree of uncertainty conveyed by a wide spread in the initial estimates. Planning Poker benefits. Planning Poker is a tool for estimating software development projects. It is a technique that minimizes anchoring by asking each team member to play their estimate card such that it cannot be seen by the other players. After each player has selected a card, all cards are exposed at once.
Used when we have a lot of User Story to estimate, the Wall Planning Poker and a variant of Planning Poker card.
Introduction
Wall Planning Poker is a variation of Planning Poker Card that is used to estimate more macro projects. Beyond of a hundred User Story, the use of Planning Poker Card is too long.
Proceeding
1 – Bring the team together
Planning Poker Wikipedia Francais
The first step will be to bring the project team together. All the people of the SCRUM Team and the Product Owner must be present.
2 – Put the cards 'size' on the wall
At first, we will align on the wall the different cards giving the indication of the 'size' of the User Story and represented by the numbers: it can be the number of tasks allowing to realize the User Story or the time in hours / day to realize them. The rule is to be identified at the beginning of the estimate by the Product Owner. Each representing a column.
As for the Planning Poker Card, the values of the cards used follow approximately the Fibonacci law : ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞
We will pay attention to the necessary place. Given the number of cards, it is generally advisable to provide a square 4 to 5 m long and 2 to 3 m high..
3 – Identification of the standard User Story
We will pay attention to the necessary place. Given the number of cards, it is generally advisable to provide a square 4 to 5 m long and 2 to 3 m high..
3 – Identification of the standard User Story
To make a better estimate, the principle will be based on a comparison with standards. For each column, we will define a standard User Story that will become our basis of comparison for our estimates. We will identify it visually in a different way from the User Story cards (card surrounded by black in our example).
Attention, the standard must be positioned according to the 2 axes :
- In X : The 'Size' of User Story
- In Y : The priority level of User Story. The priority can be evaluated according to various criteria such as the importance with respect to the customer, the development strategy (new technologies, competitive strengths …), value of the company, ROI or 'I think this is more important than that but I do not really know why ».
4 – Distribution of User Story
The Product Owner will then distribute to each person or each team of people the set of cards with each of them a User Story. The Product Owner makes a short description if necessary.
5 – Estimate
All the people on the team or different teams then have a predefined time (about 30 minutes) to estimate the time they think necessary to achieve the User Story. For this, they will perform for each User Story map a comparison to the User Story Standard and position their map in the column that they think is most appropriate.
Throughout this estimate, the Product Owner is available to answer questions. He will recall, that this is an estimate and that it is not definitive. This can be reviewed at a later iteration.
Planning Poker Wikipedia
6 – Validate a 'value'
Once the time is up, each person or team will compare their estimate with that of others. The teams will be available to each other to justify their choice and exchange, and will move the cards if necessary. The final issue is that all cards distributed for the same User Story are in the same estimation column. This will be the value that will be used for planning.
Some important rules
The rules of operation are the same as for the Planning Poker Card.
Source
1 – M. Cohn (2005) – Agile estimating and planning
V. Messager Rota (2014) – Architecte Logiciel
