planning poker: a primer

Prerequisites

Planning Poker requires a set of Stories. It is best practice for the set of stories to be shared in advance of the game so that each player has had time to review them. This will keep each round focused on the discussion rather than understanding what the Story is about.

How It Works

Roles

There are two roles in Planning Poker: Player-Dealer - Shares a screen and updates tickets based on outcomes of each hand Player - Votes on each hand

Prior To Playing

• The Player-Dealer will collect tickets that need estimation into a collection. These should be shared with all Players in advance to allow for pre-reading and questioning (this is commonly called refining)
• The Player-Dealer will create a new room on Scrum Poker Online and will share the room link with others in the meeting.

Playing A Round

• The Player-Dealer will show a ticket from the backlog.
• All players will play the card associated with their estimated Story Points needed to complete work. This is the “bet”
• Once all bets are placed, the Player-Dealer will reveal the estimates.
• If the bets do not all align on a single estimate, the team will discuss to clarify discrepancies and seek agreement.
• Player-Dealer will clear the bets and move on to the next ticket.
• Repeat steps 1 to 5 as needed / time allows.

General Timing Considerations

If a ticket meets the prerequisite conditions, then a round will typically take between 30 seconds and 1-2 minutes in the case where the team has broad consensus and additional discussion is needed to achieve alignment respectively.

Each round should be capped at 5 minutes. If a round reaches that threshold without consensus, the Player-Dealer can hold a vote to continue the conversation (explicit opt-in). If that vote fails (i.e., the team decides not to continue discussion), the ticket will be placed at the end of the queue and will be revisited as time allows.

Thinking In Points

What is a Story Point?

Story points in scrum are an abstract measure to represent the complexity of implementing a user story. In general this “complexity” is related of course to effort, but also to risk and difficulties foreseen. The measure is abstract, because it cannot be related to a unit of time such as person days or hours.

• Scrum Poker Online

What Story Points are not

Story points are not a measure of individual effectiveness / value delivered. A team’s velocity is sensitive to the members of a team, how each member scores complexity, and therefore, a team’s velocity is an internal measure only. Teams should not be compared using velocity.

Why use Story Points?

Story Points are useful at the team level. In aggregate, they provide visibility into a team’s ability to deliver work. In aggregate, they provide a view of a team’s velocity and can be useful to understand how much work a team is capable of delivering in a given sprint.

Over the longer term, understanding our velocity allows the team to work toward predictability at a sustainable pace.

More than anything, however, the act of pointing stories creates space for conversation. When team members bet wildly different amounts for a story, it reveals a gap and encourages the team to dig in to understand why there are divergent opinions. Maybe one team member sees something the other is missing and the scope is actually much larger than others were expecting. Or, maybe they know the code better and that the team will be able to deliver the value with a small change.

In either case, the act of betting with story points helps reveal these differences helping the team understand what’s involved in the work prior to starting it.

Does “who” affect “how many” Story Points?

As a general rule, Players should estimate story points based on their (individual) expectation for the level of complexity. While this does mean that individuals who are more familiar with the problem space may bet a smaller number of points than others, this is okay as the differences will be resolved in the conversation following betting.