Planning Poker is an Agile planning and estimating technique. It is a consensus-based technique used to estimate the product backlogs by the Agile teams worldwide. Planning poker is done with story points, ideal days, or any other estimating units. To estimate the Product Backlog, a customer or Product Owner reads the user stories or describes the features of the product to the estimators.
Planning Poker is a technique for sizing PBIs.
Planning Poker technique was first described by James Grenning (Grenning in 2002) and then popularised by Mike Cohn (in 2006). Planning Poker is based on the following few important aspects.
Planning Poker technique estimates the efforts. In the activity, the experts engage in the discussions on Product Backlog Items (PBIs) to reveal the assumptions, gaining a shared understanding, and sizing the PBI. Planning Poker produces relative size estimates by grouping the similar-sized items.
Estimation Scale provides a sequence of numbers to assign estimates for implementing Planning Poker activity. Generally, a team doesn’t use all the numbers from the scale as the goal is not precise. Rather, a team support a scale of sizes with more numbers at the little end of the range and more broadly separated numbers at the extensive end of the range.
Mike Cohn has proposed one scale based on a Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, and 100. This is the most frequently used scale in the Agile organizations. Some teams use the scale which is based on powers of 2: 1, 2, 4, 8, 16, 32, . . .
The teams group the like-sized PBIs together and the same number is assigned to them while using this type of scale. To illustrate the concept, consider one example of a postperson at post-office. The postperson groups the same area letters in the area-wise boxes (from a close area to far) to ease the process of letter delivery.
Similarly, the team members (estimators) discuss the PBIs asking questions to the Product Owner. When all the features are discussed completely, an estimator picks up one card to depict team members’ estimate. At the same time, all cards are then revealed to others. If all the estimators choose the same story points, that will be the final estimate to that story. If not, the team members discuss their estimates to come to a conclusion.
The high and low story points estimators need to share their reasons. After a discussion, each team member again selects an estimate card and all the cards are again made open for all at the same time. This process continues until the team reaches the consensus or the estimators come to a point that Agile estimating and planning of a particular item needs to be postponed until an additional information is obtained.
Most of the teams hold a Planning Poker activity soon after an initial Product Backlog is composed. This session is used to create the initial estimates that will be useful in sizing the project.
Teams find Planning Poker activity very helpful for conducting Agile estimating and planning sessions once per iteration.
Planning Poker activity is used to evade the impact of the other participants. If one number is spoken, it can be viewed as a recommendation and impact other team members’ estimating. Also, Planning Poker compels individuals to think freely and propose their numbers simultaneously. This activity is accomplished when all the team members reveal their card at the same time.
The Scrum Master, Product Owner, and the development team participate in Planning Poker activity. The Development Team sizes the user stories.
During the activity-
A common interpretation of numbers on the Poker cards is described in the table below.
The rules for playing Planning Poker activity are as follows.
Planning Poker is an engaging act and a productive approach for estimating the user stories. As, the activity is all about a discussion, not only is it painless for the team members to arrive at a consensus but also provides a wide view for implementing a user story at hand.
Very nicely written!
i want to know more as a scrum master
Why would you justify your phrase " the same holds true for a Scrum Master, who must understand the technical issues the team needs to address and the technologies the team will use to come up with end solutions." using the Scrum Guide? There's nowhere in the Scrum Guide saying that Scrum master must have technical knowledge, so I would like to understand what is the rationale /logic behind this phrase.
Okay thank you so much for the info and you have mentioned in the blog.
I am really happy to read this blog as I was stuck in this type of problem many times and your blog solves my problem in one go. I can't wait to see your next post soon.