Pass a set of cards to each member of the Development Team.
Follow these steps to play:
- Take the next User Story from the top of the Product Backlog and read it out, including the acceptance criteria.
- Place the story card in the middle of the table so that others can see and read it if they want to.
- Ask if everyone has had enough information to size it. If they don't, give the team the opportunity to ask questions. When everyone is ready, move to the next step.
- Each team member should be holding their Planning Poker cards in such a way that the card values are hidden from other players. You want to avoid influencing each other's choice. Ask the team to select a card representing the size they think the User Story is and place the card face down on the table. Again, they should keep the value hidden from the others.
- When everyone has selected and each player's card is on the table, the Scrum Master counts down from 3 to 1. On 1, everyone turns their card values face up together.
- What happens next depends on what value each team member selected. For example, if you have five Development Team members playing, the following are a few possible scenarios:
- 5, 5, 5, 5, 5: Everyone selected the same size; that's the story size.
- 2, 2, 3, 3, 3: There's a tight range, with only one value difference in the selection. Here, you should err on the larger story size.
- 2, 5, 8, 8, 13: There's wide range. Ask the player who put a "2," why they thought it was that size. Hear them out. Next, ask the player who put "13" why they thought it was a "13." Everyone can contribute to the conversation, but you should allow outliers to share their opinion first. Once you've heard all contributions, play another round and see if the range becomes tighter.
- Once you reach a consensus, write the agreed size on the User Story. Put the User Story to one side and take the next User Story from the top of the Product Backlog and play again.
If you can't reach an agreed-upon size for the User Story by the time you've played a total of three sizing rounds, you may need to take a different tack. One option is to try to refine the User Story further; this can be done spontaneously if the Product Owner feels that it is possible. The other option is to place the story back on the Product Backlog to be refined and sized at a later date. If one of these approaches still doesn't reduce the team's uncertainty and they still can't reach a consensus when sizing the User Story, you could consider performing a Spike.
When the Spike is selected for the next Sprint, an investigation will be carried out, the outcome of which should inform the way forward for team. The results of the Spike will likely generate further User Stories. Agree on a timebox for the Spike, which once complete is used to ascertain if you've gathered enough information. If you have, the team should stop the investigation and share the results. If more time is needed, you should negotiate with the rest of the team, including the Product Owner, and increase the size of the timebox if agreed.
NOTE: Spikes should be used sparingly. It can be a bad sign if a team is regularly running investigations on how to implement User Stories, as there is always a degree of uncertainty around any of the work that's carried out—a natural part of our process is uncovering more information as we go. Spikes should only be used when there is an unusually high level of doubt.
When using an estimation process such as Planning Poker, group involvement gets a better estimation result because of the benefit of group wisdom. Each member will bring a different experience on what is needed to be done to achieve the story, giving the group the opportunity to improve the accuracy of its estimate very quickly. This method is also a fast way to determine what is and isn’t known about a particular story.
Group involvement also serves to inform each member of the team about a particular User Story, and this understanding will help them implement the story more quickly when it's bought into and worked on in a Sprint.