Select Page

## Planning Poker

Planning Poker is a flavor of the Wide-band delphi estimating technique designed to get the whole team involved in estimating the size of user stories.  The estimates are done using story points – a unit-less metric for estimating things using relative size.

### Select a Scale

There several options for selecting a sizing scale, the most common are a modified Fibonacci series and “t-shirt” sizes {XS, S, M, L, XL, XXL].  Most planning poker “card” decks use a modified Fibonacci series {0,1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, …} and often include a “?” question mark card for those stories that the team doesn’t think they can estimate at all.

I have used both approaches and found that either works well.  Some teams seem to prefer t-shirt sizes, some prefer using the Fibonacci series.  In either approach, I tend to restrict the cards to 1 through 40 and add a “black dot” card for those that individuals feel they just can’t size without more discussion or breaking down the story.  In fact, the Perigee Consulting planning deck that I use has cards for both t-shirt sizes and a modified Fibonacci series {1,2,3,5,8,13,20,40}, and of course a “black dot” card.

The planning poker process

– Start with a deck of cards that have numbers associated with the estimating sequence we are using. (Fibonacci series: 1,2,3,5,8,13)

– All team member get together, including the product owner.

– The mediator (often then scrum master) take story card from the stack and reads the description.

– The Developers ask clarifying questions about the story to the product owner.

– Each person on the team selects a card with an estimate (in story points).

– Everyone turns their estimate card over.

– The high and low estimates are explained. What is the estimator thinking. What information do they have to lead them to a high or low estimate.

– The team discusses the details, and if needed, selects a new estimate to present to the team.

– The agreed upon estimate (again, in story points) is written on the story card.
I have found that planning poker is useful, and easy for the team to get started with.  It also provides consistent sizing, brings up a lot of good discussion, and helps build the teams tacit understanding of the product they are developing.  It is, however, a bit time consuming and can be exhausting for the team to go through large number of stories.  If possible, prepare the team for some marathon estimating sessions or be willing to break the estimating sessions into smaller time boxes of no more than 4 hours in length.  (This, of course, will mean it takes more calendar time to come up with your first sizings of a backlog for early planning – but may be needed to save the teams sanity.)