.png){kind=logo}
Why planning poker works?
Here are some reasons for playing planning poker:
The people doing the work do the estimates
Estimator have to justify estimates
Most estimates are within one order of magnitude (most of them between 1 and 10, actually it should be so)
Combining of individual estimates through group discussion leads to better estimates
Emphasizes relative estimation rather than absolute estimating
Prevent time wasting while estimating, because of using specified numbers
Quick and fun
It helps avoid anchoring (the tendency for estimates to cluster around an irrelevant value) by making sure all cards are turned over at the same time
The rule in Planning Poker is that the team needs to come to agreement on the estimate to be given to a product backlog item. How to achieve this is up to each team. Some teams will decide to average individual estimates after some number of rounds without agreement. In general, it is best to avoid rigid rules like this since knowing that estimates will be averaged after a certain round can introduce dysfunctionality into the process.
After a round of cards is shown, any estimator is allowed to explain the reason for their estimate. At a minimum, though, the high and low estimators should explain their estimates.
One of the biggest advantages to Planning Poker is the discussion it creates. These discussions excel at uncovering team members’ differing hidden assumptions.
Although the entire team should be present when estimating, the product owner and ScrumMaster or coach will usually estimate only at the invitation of the team. If these individuals were formerly technical or have solid development backgrounds, the team may ask them to hold up cards during Planning Poker. Otherwise, the product owner is present to explain the product backlog items and answer questions, and the ScrumMaster or coach is present to facilitate the meeting.
During planning poker, we have two likely problems:
Product uncertainty
Technical uncertainty
To resolve those problems there are two good solutions:
Put the story aside until the uncertainty can be resolved
Or consider using a range as the estimate
A good approach when estimating is relative estimating. One challange with relative estimating is how to get started. Find 2 and 5 point stories, or 1-5 or 2-8. So you can use a base range with those two stories while estimating. Now you are ready to start to play planning poker with relative estimating.
Before a team begins estimating their product backlog they should agree on a set of valid estimates. That set could be something like 1, 2, 3, 5, 8, 13, … or 1, 2, 4, 8, … or 1, 5, 10, … and any other set of values as long as the values chosen are sufficiently far apart that team members can truly distinguish between them.
A team should not decide to artificially constrain themselves to using just the range 1–10. Although they may split product backlog items so that most fit within that range, there is no reason to permanently rule out the use of larger numbers. Occasionally someone may want just a very rough estimate and using a larger number may be sufficient (and faster) in that case.
Similarly, although it is generally good to work with small product backlog items, a rule that says every one should be made as small as possible will lead to too many items on the product backlog.
Anchoring
When an estimator looks through a set of Planning Poker cards, mumbling, “Where’s that eight?”, this anchors “eight” in the minds of the other estimators. Regardless of what the others think of this person’s estimating skill or knowledge of the given product backlog item, they will derive their individual estimates by adjusting up or down from having heard eight.
After a round of estimating, it is entirely appropriate for estimators to defend their estimates by analogy to other estimates. This is not anchoring because each estimator was first given a chance to estimate without hearing the estimates of others.
When someone starts a meeting by describing expectations such as the need to finish the top eight product backlog items during a release, this anchors the team’s estimates. They will have in their minds that at least eight items should fit in the desired timeframe. It would be better for the ScrumMaster or coach not to share that information until the team has estimated those items first.
Having an agreement that any product backlog item estimated at some number or above should be split is a common team agreement. Although this would be better as a team guideline than a hard-and-fast rule, it is not anchoring because it is not a comment on the size of any specific product backlog item.
References
https://www.frontrowagile.com/courses/agile-estimating-and-planning