Planning Poker at Coders House
How big is the task and how long it will take? We have asked ourselves these questions so many times that we lost count many months ago. Fortunately, we also found a solution that answers them perfectly. Ladies and gentleman, meet Planning Poker!
We want to play… I mean: work!
Planning Poker – also called Scrum Poker – is an effective estimation technique. It works well for agile software development, because instead of calculating the exact number of hours the work will take, it helps to estimate the complexity of tasks. It is really much more appropriate for IT projects, trust us.
So, who usually is invited to “play”? The poker is available for every member of the project group, including developers, designers, testers, managers and so on. Each estimator gets a deck of cards at the beginning of the game. All cards have a written number on them (0, 1, 2, 3, 5, 8, 13, 21 or 34. Yes, it’s Fibonacci sequence). We call them Story Points. The numbers are large so that everyone can read them at ease and they are used to determine the size of the estimated work. Sometimes there is also a “coffee” card and a “question mark” card in a deck. They mean “we need a break” and “I can’t estimate it”, respectively. We have decided to upgrade the first one, so our “break time” card is actually a “pizza”. Because who doesn’t like pizza, right?
Let the game begin
It all starts from the moderator (usually – Project Owner). He gives the group a description of the task that needs to be done. At this point, questions can be asked. They are pretty important, because they are the key to a productive discussion. A few moments later the estimations begins. Everyone except the moderator starts by laying a card face down on a table. The number represents their estimate for the given story. Then it is time for the big unveiling. Each estimator turns their card over. Important thing: it needs to be done simultaneously. Now, about the results:
- If the estimates are similar, it means that the whole group understands the task pretty well.
- If the estimates differ slightly, the team should deal with uncertainties and discuss the choice.
- If the estimates differ significantly, members who showed the lowest and the highest number describe why they decided to go with such an estimate. It is a great way to discover what potential problems
- and obstacles they see. After the talk, each team member chooses a card again. Usually, the numbers in the second round are alike.
- If the discrepancy is still there after several rounds, this means the task is too complex for the team and should be explained once more in more detail.
Still wondering why does it work so well for software development? The game is based on data that comes directly from people involved in the project. They make the best estimations, because they are committed and want to achieve the best possible results. We use knowledge of the entire team. Once again, it’s strength in numbers.