From the course: Agile Foundations

Planning Poker

From the course: Agile Foundations

Planning Poker

- One of the most popular ways that Agile teams combat groupthink is by playing a game of planning poker. This is a consensus building technique that was adapted from a group decision-making tool called Wideband Delphi. Planning poker helps groups of people estimate how much effort it would take for the whole team to finish a user story. It's a way to get a shared understanding about all the development and design challenges to deliver that small batch of work. So let's take a look at how this works. Your team sits around a table. And a facilitator, usually the scrum master, holds a user story that the product owner wants delivered. Each person on the team will have a set of playing cards. The numbers on the cards represent relative effort. The higher the number, the greater the effort. You can use any range of numbers, but the most popular range is a modified Fibonacci sequence. So something like one, two, three, five, eight, 13, and 21. So everyone on the development team sits around the table. Then the scrum master reads the story out loud and puts it face up in the middle. Each team member estimates the effort in the story and places the card face down in front of them. The number on this card represents a team member's view of how much effort it will take for the whole team to deliver the story. This is a really tricky concept for a lot of teams. Many of them come from a project management background, so they might think of it as individual work hours. But remember, you have to finish the story in a two-week sprint, so think about the effort it will take for the whole team to finish the story in that time box. Once all the cards are down, the scrum master asks everyone to flip their cards over all at the same time. They do this to make sure that people don't influence each other's estimates. It also encourages the team to have a conversation and avoid groupthink. What often happens is that there'll be a wide range of different estimates. One person might have a two, another person will have a 13, or one person might have a three, and the other person will have a five. When this happens, the scrum master should ask the person with the highest number to explain to the person with the lowest number why this story will need much more effort than they estimated. The key thing to keep in mind is that this is a consensus building exercise. In many ways, the numbers are irrelevant. The important thing is that everyone reaches consensus for how the whole team will deliver the story. What you don't want to see happen is that people will just give up the discussion for the sake of reaching a number. They might say something like, "Since you haven't eight and you're the expert, "I'm also going with an eight" just to keep the game moving. It might take a few rounds of playing until everyone has reached consensus. That's okay, because it's better to have that discussion before you start delivering the story. The scrum master should make sure that everyone has this conversation so there's a shared understanding of how everyone will deliver the story.

Contents