What is Planning Poker?
Planning Poker (or Scrum Poker) is a method for estimating the workload associated with implementing a User Story or an Epic. This method is generally used during Backlog Refinement (or Backlog Grooming) sessions in preparation for the Sprint Planning session to size the backlog items and possibly refine the User Stories, i.e., cut them into two or more smaller User Stories.
Estimates are generally given in Story Points to estimate the workload of the different elements of the backlog in a relative way. You can rely on the acronym CURSE to define the parameters the Story Point must aggregate:
- The Complexity encompasses the User Story’s own technical difficulty as well as its intertwining with other components of the system;
- The Uncertainty reflects the possible lack of information or assurance regarding the technology or the impact on other system components or the architecture itself;
- The Risk associated with the change brought by the functional or technical evolution, whether on the system, the design, or the architecture;
- The Scope of the components likely to be impacted by the functional or technical evolution;
- The Effort represents the effective work necessary to implement the functional or technical evolution.
The cards used generally take the numbers of the Fibonacci sequence: 1, 2, 3, 5, 8, 13, etc. The fact of using a sequence with a non-linear progression contributes to the relative nature of the estimate.
Story Points introduces the concept of velocity, the cumulative number of Story Points a team can achieve on average over a sprint.
How to run the Planning Poker session
Organization of the Planning Poker session
The Scrum Master commonly facilitates the Planning Poker workshop. The Product Owner is responsible for describing each User Story on a functional level, specifying the business needs and constraints. The technical elements should not be discussed at this stage.
Only the development team members should participate in the vote. The Scrum Master and the Product Owner should, therefore, not participate. If in doubt about understanding the User Story, members of the development team should ask the Product Owner for clarification.
The first round of estimation
Once the User Story has been presented, the Scrum Master activates the polling booth mode and invites participants to jot down their estimates. When the polling booth mode is enabled, the contents of newly created objects are not visible to other participants.
Once all the participants have indicated their estimate, the Scrum Master deactivates the polling booth mode and reveals the contents of the stickies. All team member estimates then appear at the same time on the board.
The different scenarios, according to the results of the estimation
Depending on the results, several scenarios may arise.
Scenario 1: Perfect Consensus
All participants write down the exact estimate. The Scrum Master then validates the estimated Story Point and indicates it on the corresponding User Story.
Scenario 2: Satisfactory consensus
The participants indicated different but close estimates, i.e., with only one rank difference between the lowest and the highest estimate. The Scrum Master then retains the highest Story Point value.
Scenario 3: Lack of consensus
Two ranks separate the lowest and highest estimates. The Scrum Master invites the participants with the lowest and the highest estimates to elaborate on their estimations. The exchange must be brief and limited to a one-minute maximum.
Once the exchange is over, the Scrum Master restarts a round of Planning Poker to collect the estimate of the members of the development team in light of the arguments that have been presented.
At the end of the 2nd round of estimation, you should normally be in scenario 1 or 2. If this is not the case, repeat the exercise of scenario 3 until you reach a perfect or satisfactory consensus.
Validation of the estimate or refinement of the User Story
If the User Story has an acceptable estimate, usually less than or equal to 8, the User Story is validated and considered ready to be added to the next Sprint Planning.
In the event that the consensus leads to an estimate greater than 8, this may mean that the User Story must be split into two or smaller User Stories.
