Need for relative sizing of estimates
Agile methodology is all about “plan as you go”. With insufficient or little detailed requirements available upfront, it becomes impossible to come up with precise effort estimates to determine the size of the entire project. Since the Product Backlog evolves throughout the lifecycle of a product, only the epics and/or the user stories that may potentially provide highest return on investment are elaborated to greater detail, which the development team pulls into sprints for development. A common “measure” is required to size the effort of the epics or user stories across the board. Given the nature of details available, a relative scale would provide a reasonable mechanism to measure the size of user stories.
Planning Poker
Planning Poker is one of the common estimation techniques used by Scrum teams to come up with a high level consensus estimate. It provides an easy way to arrive at an abstraction to time.
Planning Poker is fun. Why will it not be when the teams are allowed to officially play cards at work! Well, with a different variety of cards though. It is more efficient since it brings the whole development team together in the estimation process instead of relying on individuals for estimates.
Poker cards deck
Create a deck of blank cards. Write a unique numeric value on each of the card. Since the idea is to come up with a relative sizing estimates than accurate estimates, it is recommended to keep the number of numeric cards limited, say 10. This will help in easier relative sizing than pursuing a precise value.
A common representation of numeric values written on the cards is Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, and so on. The advantage of using the Fibonacci series is that it easily enables a comparative thought process than giving room for induced accuracy. This type is typically used for Product Backlog estimates and it becomes the scale for determining story points for each user story. If a series of consecutive numbers are used, the team may end up invariably equating it to days or hours trying to thrust accuracy into the estimation process.
However, as a variation, Planning Poker can be used for Sprint Backlog estimates as well, in which case, more accurate estimates are possible since the user stories picked up for the sprint at this stage would be more detailed and clear. For such cases, consecutive numbers representing hours scale can be used.
Some teams also add a card with infinity sign to use when it is felt the estimates could be way higher than the highest numeric value card given in the deck. Question mark card can also be used if someone feels there is not enough clarity to do the estimation.
Voilà! Your card deck is ready.
Deck of cards to play Planning Poker Now, replicate this card deck into multiple copies, one for each team member. After all, Planning Poker cannot be played solo.
Let’s play
The team picks up a user story from the backlog and discusses the details. Each team member arranges their deck of cards and holds it without revealing to other team members. Team members ask questions to clarify, if additional information is required. Once there is sufficient level of comfort in understanding the requirement, each team member picks up a card from their deck representing the size of effort in their guess. All team members should have picked up their card and made up their mind. Then, all team members place their cards on the table simultaneously. If this is not done synchronously and if there is a delay in some team members picking up their cards and placing on the table, there is a chance that they may get influenced by looking at the card values other team members have chosen and placed on the table.
Once the cards are placed on the table, the values are compared. The team members that have placed the lowest value and highest value will be required to explain their thought process and reasoning behind the value they have chosen. The team discusses the requirement further to bring in more clarity in understanding. The team members pick their cards back and get ready to play again. With the updated understanding of the requirements, each team member chooses their card and places on the table again.
This process is continued until the gap between card values narrows and finally the average of the values is noted down as the estimate for the user story.
Benefits
Though there are variations to how Planning Poker is played by teams, the bottom-line of using this technique remains the same. Since all the team members are involved in the estimation process, there is a clear buy-in for the estimates that have been arrived at, resulting in increased ownership in the team. Planning Poker helps both business users and the technical teams by providing a mechanism to measure the progress and forecast, and help to make informed decisions during the course of the product development.
