The importance of planning poker

When you practice the scrum process, then one of the artifacts is planning poker. It is a method to gather estimates for the stories and with teams new to scrum it is always a tricky journey how to use this efficiently.

Why

So first the why question; why not have a list of stories and forgo the estimation? We all know estimating is hard and is mostly incorrect anyway. For me there are two main reasons to do estimations;

1. It allows for a discussion about the story and to come to an agreement on how to tackle the completion of it.

2. Estimated stories and a known velocity gives a rough indication when something can be picked up.

Playing the game

Number one is IMHO the most important one. During the refinement session, the Product Owner describes the story. So basically what he/she wants to have delivered. The team should have a definition of done, therefore there is an agreed framework of when the story can be considered completed. This way both the business and the team are aligned when the story is delivered.

Of course, the team can raise questions to the PO to get the clarification they need and this will be mostly on the acceptance criteria.

There might be a discussion on how to tackle and implement the story, some ideas pop up, a drawing can be created and in the end, there should be some sort of consensus on how to complete the story.

Time for estimations and important is not to influence each other as it is too easy to look to at others. People tend to follow the more technical leaders, are afraid to say they actually do not know or think they will not be the person doing the work themselves anyway.

As the scrum master, you want to avoid this and still want to come to a sensible estimation. Playing planning poker can help here.

How

The concept of planning poker is pretty simple; each team member has a set of cards. They are numbered like 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40 and 100. There is also a question mark and coffee cup card for obvious reasons.

When it is time for the estimation of the story, ask each team member to pick a card, but not to show the card yet. To be sure everybody has picked a card and cannot change it afterward, let them put it down on the table without showing the value.

Turn the cards around all at once and see the results. If all the cards have the same value, then this can be coincident, but mostly you will see a difference.

Important now is to have the discussion. Somebody with a low value might think it is just an easy task because he has done it before. On the other hand, he might also forget some elements. A high value might be because somebody is unclear of what needs to be done or has experience with it and knows some of the difficulties in the work.

So let the lowest and highest value have a discussion to explain the values. This need to be a meaningful explanation and make sure the estimate is not based on business priority as that is not for the team to decide. If the person does not give a good reason for his value, then let him explain why it won’t be the high value instead or how it compares to a similar story.

Do not do this too long. Give two or three people a chance to explain their estimation. Then do a re-estimation. People now know what kind of estimates have been given so they are biased. However, the earlier discussions could have helped to get to a better value. All these talks will help to shape how the team is going to implement the story. Having this on a technical level is fine as it helps to discover the problems and provides clarity when the story is picked up in the sprint itself.

if the second round has again differences, then you might consider hearing the low and high estimaters again. But when there are no new arguments, do not spend too much time on it.

You can pick an average value instead as it will be an estimation after all. Take some time in the retrospective to see if it was estimated correctly.

When

Do these kinds of estimation rounds during your sprint. Take maybe 2 times an hour to go over new stories. Do not spend too much time on each story and if you see it ending in all kinds of business discussions, throw it back to the product owner so they can work on a better story description.

Try not to do refinement during the planning phase (in which you should decide which stories to actually pick up in your next sprint). At that time it is too late to get back to stakeholders with questions or do some investigations.

Conclusion

Planning poker is an essential part of scrum as it gives us not only relative values to stories, but it is also a consensus based way to have a discussion about the way the story will be completed. Not doing it, or even without hiding the cards, will lead to incorrect estimations and assumptions and in the end to an unknown and not shared way of how to implement the story.