- One of the most popular ways that agile teams
combat group think 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 1, 2, 3, 5, 8, 13, and 21.
So everyone on the development team sits around a 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 group think.
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 just give up the discussion
for the sake of reaching a number.
They might say something like,
"Since you have an 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.