The Planning Poker Card is a fun and consensual method for planning projects. Used extensively in SCRUMs, this tool can be used for any type of project.
The Planning Poker Card is a time estimation method developed by Mr. Cohn 1 who adapted it himself from the planning game used in the XP method. The objective is to estimate in a team the delays of realization of the projects. P>
The principle is rather simple : each person on the team will make an estimate. This estimate is then compared with the estimates of other people to retain only one value.
1 – Bring the team together
The first step will be to bring the project team together. All persons of the SCRUM Team as well as the Product Owner must be present.
It should be noted that for a good estimate, it is advisable to be at minimum 5 people.
2 – Distribute the cards
To each person, we will give a deck of cards, each with a value : 0, 1, 2, 3…
The values used follow approximately the Fibonacci law : ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞.
3 – Presentation and exchange of the User Story
The Product Owner will present the User Story. The goal is for everyone to understand the subject and agree on the expected. The team will have to ask all the necessary questions so as not to leave shadow areas.
4 – Choose the theme of choice
The Planning Poker Card is used for two purposes :
- Or for set the number of tasks necessary to complete the Story. This is the case when a User Story is complex that we will cut into “Story Point”.
- Let identify the number of hours or days needed to complete a task. These are the Ideal Day quot which represent the completion time of each User Story or Story Point.
5 – Estimate
All the people on the team will make an estimate of the number of Story Points or Ideal Day by simultaneously presenting the card with the corresponding retained value..
The reflection period is of the order of 1 to 2 minutes.
6 – Validate a “value”
Always in a group, we will compare, analyze and discuss the proposed values to retain only one. The goal is to obtain consensus in a friendly and fast way, allowing everyone to express themselves and justify the choice of his figure :
- If all the estimates are convergent, then we will validate the result as is.
- If the estimates do not converge, the discussions will pick up particularly between the people with the biggest points differences.
Some important rules
Rule 1 : Have a similar knowledge of the subject
A poor estimate may be due to a lack of mastery of the subject, or the level of control too disparate. The fact that the Product Owner details the User Story can reduce the risk, but not eliminate it.
Thus, if the level of knowledge is too unevenly distributed, we will be able to :
- Either make pairs of people (a senior with a junior) to make the estimate.
- Either people choose the stories they want to estimate (with a minimum of 5 people per estimate) based on their level of knowledge.
Rule 2: Ensuring Exchange and Consensus
Another essential point is to ensure that everyone can express themselves freely while avoiding soft consensus. The moderator of the session will have to make sure of this and limit speaking time if necessary.
1 – M. Cohn (2005) – Agile estimating and planning
V. Messager Rota (2014) – Architecte Logiciel