What is Planning Poker?
Planning poker is an estimation technique used frequently by agile scrum teams. It is a helpful way for agile team members to generate discussion around stories and tasks, and to estimate the effort that these will require.
Who Should Participate?
The view on participants varies widely. Some say that only developers should estimate story points using planning poker, others say that all scrum team members should help. I tend to fall into the later camp. It is helpful up front to decide if your team will estimate development efforts and test efforts separately, or if for each user story, the estimate will include both development and test. Neither method is right or wrong, but consistency is very important when tracking team velocity and when making commitments.
What is Needed to Play?
Each agile team member will need a set of numbered cards or an app to show their bids. Typical card sets contain 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100. They may also contain a ? and an infinity card. Each team member should have a full card set.
How Do I Play Planning Poker?
To play planning poker, the team should select an item off the backlog – a story or task. The team should discuss what this story means and ask/answer any questions that team members have about the task as well as possible without further research. Each team member should then select a card that corresponds to the relative effort they feel that the story/task will require. The unit of measure should be story points. A story point is relative to the team, but should be consistent among team members. For example, team A might consider a story point to be about a day’s work, whereas team B typically completes story points in about four hours. After all team members have selected a value, they should show their values at the same time. If there is consensus, that effort should be recorded with the story in the backlog. If a small number of team members disagree, they should discuss why they chose the values they chose. If there is consensus after discussion, then record the decided value. If not, the team should each privately select a new value, reveal and discuss until consensus is reached.
If a team cannot reach consensus, then it is usually good to create a research task (a time-bounded task) to investigate how much effort will be required and come back to the group in a future planning session with more information about the story/task.
If the team agrees that an item has a large sizing (typically larger than 8), they should strongly consider making that story an epic and breaking down the work into smaller stories/tasks.