With the introduction of agile development methods, planning poker has found its way into our company as an estimation method. Here you can find out exactly what Planning Poker means, how this estimation method works and what advantages it brings.
What is Planning Poker?
Planning Poker is a standardized "estimate meeting" that takes place regularly before the start of a development phase (sprint). This method is used by software developers as part of Scrum. In contrast to classic estimation methods, Planning Poker does not evaluate the effort or the duration of implementation, but the complexity of a feature. In this way, timeless estimates are created that are independent of the experience and speed of specific people. The goal of Planning Poker is that all user stories presented by the product owner are provided with so-called story points. On this basis, the product owner prioritizes his product backlog in a further step.
The method goes back to the American software engineer Barry W. Boehm. With the function point analysis, he shifted the focus away from the implementation time towards the complexity. In 2002, James Grenning developed the Planning Poker game, which became internationally famous through Mike Cohn's book "Agile Estimating and Planning".
The poker cards have the following numbers: 0, 1, 2, 3, 5, 8, 13, 20, 42, 100, pause and a question mark. The values are derived from the Fibonacci sequence. The complexity increases with the number. The two cards with the coffee cup and the question mark are joker cups and mean that the player needs a break or, in the case of the question mark, has no idea.
The goal of every sprint is that all user stories are completely finished at the end. Experience has shown us that user stories should no longer be scheduled in a sprint after a certain number of story points. In a two-week sprint, a story with a complexity of 20 is already classified as high risk. It is therefore advisable to break down such a user story into further sub-stories in order not to jeopardize the sprint goal.
How does Planning Poker work?
A moderator or the Scrum Master equips the team with Planning Poker cards. Then the product owner presents his first user story (feature). At this point, the development team is encouraged to ask questions and discuss risks. It is important that at the end of the discussion all team members have understood exactly what is to be implemented. When there are no more comprehension questions, the complexity of the first user story is estimated. Incidentally, the estimate is often based on an already known and valued reference story: “What is the relationship between the story just presented and the reference story?” This makes the estimate easier. Each team member guesses individually and places the card face down on the table. Once all members have finished, the moderator instructs all cards to be turned over at the same time. If the values within the team deviate significantly, the reasons are discussed. The estimation is repeated until the group is in agreement and can deliver a concrete value for the respective feature.
Experience has shown that discussions often arise when planning poker is introduced, especially in cross-functional teams, because team members do not see themselves in a position to make an estimate. Possible causes can be that they are not responsible for the implementation of a story or have a lack of specialist knowledge. However, it is completely irrelevant who will implement which story later in the sprint or how much experience someone can draw on. In planning poker, it is crucial that the most important characteristics of a story and possible risks are identified. Therefore, each team member is empowered to make an estimate.
From velocity to predictability
Of course, even with an agile project, the client would like to know how long the implementation can take and what the costs will be for him in the end. Therefore, the velocity (speed) of a team is used for release planning. A team's velocity is the number of story points completed during a sprint. The velocity varies depending on the size of the team, the duration of the implementation phase and experience. With a well-rehearsed team, however, empirical values can be used.
In order to estimate the duration of the entire development time, the complete product backlog (all user stories that are to be implemented within a project) is estimated. The number of sprints required can be calculated using the average velocity.
What are the benefits of Planning Poker?
Common understanding
All people involved in the project are present at Planning Poker: From the Scrum Master to the Product Owner to the development team. By talking through the individual features, it quickly becomes clear what the problem is and which user stories need to be revised again. Ambiguities are therefore cleared up before implementation and clarified with the stakeholders.
team decisions
In Planning Poker, no one person decides alone. The final score is a team decision. Everyone is encouraged to join the discussion and everyone is taken seriously. There are no hierarchies that influence the result. The estimates come from the team and not the supervisors and are therefore borne by the team.
Fast feasibility
In our experience, appreciating complexity takes a bit of practice. At first, many people find it difficult to suddenly no longer give a number of hours or man-days as an estimate. In planning poker, features are valued in relation to each other. After a few rounds of planning poker in a well-rehearsed team, this makes the process easier and faster in the long run.
objectivity of the estimate
The estimation of complexity enables an estimation that is as objective as possible independent of a specific person. In contrast to the effort estimation, it does not depend on the experience of a specific developer or his speed.
In summary it can be said that with Planning Poker our teams not only get good estimates, but also the fun factor is not neglected. So it's worth playing a round of poker!