A Beginners Guide to Planning Poker

A beginners guide to Planning Poker explains the why, how and what of this agile estimation technique. Regarding to the Scrum Guide, “Product Backlog items have the attributes of a description, order, estimate, and value". However, it does not explain what “estimate” means, and leaves this open and up to the respective Scrum teams all over the globe. As classical effort estimations don’t work very well, many teams are using Planning Poker to create the estimates. But, why do we actually do this? How do we do this? What has to be considered when using planning poker? This article gives an overview and explanations regarding agile estimations with Planning Poker.

The Aims and Goals of Planning Poker

The Scrum Guide tells us, that “Product Backlog items have the attributes of a description, order, estimate, and value". Furthermore, “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog". Hence, Planning Poker is part of the Product Backlog refinement in Scrum, and its main goal is the estimation of Product Backlog items.

The addition of estimates to the Product Backlog items provides different values to the team. On one hand, the team has to discuss the Product Backlog item thoroughly in order to be able to estimate it. Hence, a common understanding of the item is gained. Secondly, the estimations create transparency about the items refinement progress and status. Items with a large estimation have to be refined further, before they can be implemented. Furthermore, the estimations are a very valuable input for the Sprint Planning. Here, the estimation serves as on of the key parameters for the actual planning, where the amount of planned work should never succeed the teams capacity.

The Setup of Planning Poker

First, let’s look at how a round of Planning Poker is set up. Who is participating and what utensils are required? As I explained earlier, estimating Product Backlog entries is part of refinement. According to the Scrum Guide, refinement is an “ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items". Conversely, this means that at least the Product Owner and the Development Team are required for a refinement meeting. In many teams, however, the Scrum Master also takes part in the refinement as a moderator or watchdog. For example, he can prevent the discussion from digressing or monitor compliance with the time boxes.

Another aspect that is defined by the Scrum Guide is the timing and expenditure of time that may be invested in Planning Poker. “The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team". Since the team has to agree on a common place and time for the implementation, these should of course be reserved accordingly. The Scrum Master also keeps an eye on the scope of the Refinement meetings. If these regularly exceed the 10% of a sprint, this should be addressed in the sprint retrospective and a corresponding solution worked out.

When the team members have gathered for the Refinement meeting, the Planning Poker cards will be distributed. The Scrum Guide again specifies which team members are allowed to estimate. “[…], the people who will perform the work make the final estimate". This means, only members who are potentially eligible for the implementation of a Product Backlog item are allowed to estimate. They will each receive a set of Planning Poker cards. These consist of ten cards with point values ​​and three special cards. First, let’s take a look at these cards themselves before looking at the flow of Planning Poker.

Story Points as Weapon of Choice

Since classical effort estimates do not work well, we have to find another method to create estimates for product backlog elements. Ideally, this technique not only allows us to cover the effort required to process the product backlog element, but also to take into account risks and uncertainties. In other words, we want to estimate the complexity of a product backlog element and not just its effort.

This is where Story Points come into play. Story Points are numbers derived from Fibonacci’s sequence. They allow us to include all the above criteria in our estimates. Therefore Planning Poker Cards show Story Points as estimates. The available Story Point values are 0, 1, 2, 3, 5, 13, 20, 40 and 100. In addition, special cards, e.g. for a coffee break, are included in the card decks.

The Execution of Planning Poker

We have already seen that Planning Poker is only part of the refinement. It is therefore useful to check which steps the refinement of a product backlog element goes through.

First the Product Owner presents the requirement to the Development Team. He explains the context, the content, presents the related mock ups and the added value for the customer. Then the requirements and possible solutions are discussed in detail between the Product Owner and the Development Team. Decisions about the system and software architecture are made here. An entry can only be estimated if the implementation path is clear.

If there are no further questions about the functionality and the solution sought, the moderator initiates the estimation, i.e. the Planning Poker itself. He asks the participants to select the poker card with the appropriate value from their deck of cards. All cards are face down and not yet visible to the other team members.

The moderator asks the participants to simultaneously display their estimated values, i.e. turn the cards over. It is important that participants are not allowed to correct their estimate after they have seen a team member’s estimate. Now there can be two situations. Possibly there is consensus on the estimate. In this case the estimate is added to the Product Backlog item.

However, most of the times the team members’ estimates differ. In this case, the respective developers explain why they estimated as they did. Once they finished the discussion, the item will be estimated again. This continues until a consensus has been reached. Obviously, this can take a long time. There is an elegant way to shorten these discussions and still come to a meaningful result.

If the team members’ estimates are only one order of magnitude apart, the higher value is used as the estimate without discussion. Apparently, at least one team member sees an increased risk, effort or uncertainty. By accepting the higher estimate, the team respects this potential risk and does not offset it. This reduces the risk of underestimation.

Introducing Planning Poker to Teams

Finally, let’s take a look at how Planning Poker can be introduced to Scrum teams. Normally it is sufficient to play Planning Poker with a new team without much preparation. In the first round the rules should be explained to the team. Due to the unusual nature of Story Points, each team should also define a “Baseline Story”. This should be the easiest task that each team member can do, and this is the representative of a single Story Point. All other stories refer to this basic task. During the first poker round the Scrum Master can support the team as a mentor.

There is no right or wrong in the estimation of story points. The only thing a team should strive for is consistency. All estimates should be as consistent as possible. In the beginning, the team will have some difficulty in estimating complexity rather than effort. Over time, however, the team’s ability to make good estimates will improve.

It is possible to visually assist newcomers to Planning Poker by using appropriate playing cards. For a Scrum Master this can also make coaching a team in agile estimation techniques much easier. At the same time the estimated scores become much more consistent. This provides a more stable velocity and thus also facilitates sprint planning. Playfully designed cards are ideal for introducing Scrum to development teams.

Final Thoughts

In this article we have given a short insight into the world of agile estimation with Planning Poker. We discussed the setup and execution of Planning Poker rounds. We also talked about the why and what of Story Points and their ability to cover risks and uncertainties in our estimates.

Teams newly introduced to Planning Poker can be supported by using descriptive poker cards. These give a graphical representation of the Story Point value represented instead of just the simple number. Teams need not fear the introduction of Planning Poker as long as some simple rules are followed. One of the basic rules is the consistency of the estimates made by the team. A beginners guide to Planning Poker can be used as a quick reference for coaches, teams and managers in the agile community.