During the sprint planning meetings, the Scrum team plan the work to be performed during the next sprint. As the Scrum sprint is a time-boxed period, the delivery of software has to be calibrated to fit in it. Planning poker is a collaborative estimation technique used to achieve this goal.
Planning Poker is a process defined (and registered) by Mike Cohn. During a planning poker session, upcoming features are discussed and refined by the product owner and the developers. Then, estimators select one card to represent the value of their estimate. All cards are revealed at the same time. The value of the scale can then be translated in story points, ideal days or other concept used by the teams to finalize the sprint planning. The usage of a scale instead of traditional man/days metric offers a simpler and stable measure of the backlog complexity, whether the effort required for each user story and the speed of its delivery (velocity) might vary during the evolution of the team in time.
It is important to remember that, as many of the Agile software development practices, the main goal of a planning poker session is to create a discussion in the Scrum team and fulfill the objectives of interactions, collaboration and teamwork promoted by the Agile Manifesto values and principles. The situation is simple if everybody agrees on the complexity of a backlog item. Otherwise, people with smaller or larger estimates should share their reasons for thinking differently than their colleagues.
Here are some of the scales used during planning poker sessions to classify the backlog items. They can be printed on a physical card or implemented in some planning poker tools for distributed Scrum teams.
Fibonacci and Modified Fibonacci
The Fibonacci suite (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89) is the most common scale used for planning poker, because it proposes good estimation ranges for both small (in the first part) and large stories (in the upper scale numbers). The original scale has give birth to a modified Fibonacci suite (0,1,2,3,5,8,13,21, 40, 80,100) that removes the sometimes unnecessary precision level of the higher numbers.
The t-shirt scale (XXS, XS, S, M, L, XL, XXL) provides a smaller and easier, non-mathematical, scale for Scrum teams that are examining the complexity of the backlog items. T-shirt size is also a concept that can be integrated by all team members. It makes the estimations less related to traditional project management effort metrics like man/days, which is good for people that are switching from more traditional project management planing approaches. Depending on the composition and interests of the Scrum team members, other non-numerical scales can be adopted, like beer or coffee drinking sizes.
The progression numerical scale (0, 1, 2, 4, 6, 8, 16, 32, 64) offers a more radical way than the Fibonacci suite to make the difference between the size of the backlog items. The gap between the scale items can influence estimators in making more varied decisions.
In a similar way than the t-shirt scale, the linear scale (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10) propose a simple and linear way to classify the backlog items. It might be easier to grasp than the Fibonacci scale, but it is more difficult to detect very large user stories that maybe should be broken in smaller items.
The Large/Uncertain/Small is a screening technique that allows to separate the backlog items in different categories and organize planning poker sessions where you can discuss initially the most difficult items to estimate.
The planning poker is a technique that is used to generate a discussion and create a consensus in the Scrum team (https://www.scrumexpert.com/tag/team/) about the complexity of backlog items that will be part of the next sprint. The abstractness of the scale used to measure this complexity allows estimating effort without getting the false sense of commitment and confidence provided by traditional project management metrics like man/days or hours. It makes also more obvious the difference between the complexity of backlog items and the delivery rate of the Scrum team during the sprint that is named velocity.
If you print planning poker cards, you should also provide estimators with options that are outside the scale, like “I have no idea”. It is also a good practice to have a card that suggested that a break is needed.