What is Planning Poker?
Planning Poker is used for the group-based estimation of sizes, usually the effort or complexity in development projects. This is exactly how the value (business value) of features or products can be estimated.
But why “group-based”?
- It avoids one-sided views (swarm intelligence).
- It promotes structured discussions in groups.
- Everyone in the group gets a better understanding about the discussed topic.
The anchor phenomenom makes it difficult to get real, individual assessments in group-based discussions. The anchor problem means, that the assessments by all discussion participants are subconsciously biased to the assessment of the first one, who initially explains his opinion (anchor). To avoid this effect, everybody has to make his individual decision secretly before sharing it with the other group members. This is exactly what planning poker cards are for.
Why relative?
There are also several reasons for this:
- Humans are better at comparative/relative estimating than estimating absolute sizes
- Real estimates are calibrated by comparing historical values. The effort actually required to implement a Backlog Item with 1 point is not known at the beginning, but can be determined after the Backlog Item has been finished. Usually not individual values are of interesting, but sums of values. Summing up values compensates errors.
And how does it work?
Just follow these simple and clear steps to successfully play Planning Poker. It is best to stick strictly to it at the beginning and only change things if you really understand the system.
- Each team member gets a deck of estimation cards.
- The Product Owner explains the PBI (Product Backlog Item) and it is discussed briefly.
- Each team member selects a card, that is his estimate.
- All cards are turned over at once, so everybody can see them.
- Differences are discussed (especially outliers).
- Repeat estimating until estimates converge.
Reference
Planning poker needs at least one reference to be able to make relative estimates. Before the first estimate, it must be determined what corresponds to a 1. When estimating effort, many teams use the definition that 1 Story Point (SP) corresponds to an effort of half a person’s day (1SP = 1/2PD).
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. .
|
Team Product Owner
. . |
Working Team
. .
|
Team Backlog
. . |