Disarming Different Estimates with a Deck of Cards

Yesterday I got hold of a deck of cards, specially made for playing planning poker at sprint planning. I’ve been through many sprint plans before but never actually played planning poker with cards. I’m stunned by the difference it made.

Without the cards, I’ve always been careful that everyone settles their own opinion first, before anyone else tells what they think. I thought that was enough to get the same results as when using actual cards. I was wrong. I was completely wrong. I spoiled an opportunity to build the team spirit, the feeling of doing this together, the collective ownership of the estimates. The most important thing I missed was the possibility to get rid of the feeling of criticism when having a different opinion. The criticism that nags on the team spirit can be replaced with a good collective laugh, empowering the team spirit instead.

The Deck

The deck of cards we used is specially made for planning poker from Crisp. It has four sets of cards. Each set has cards with the numbers 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, & 100. The 0 card means “already done”. There are also two special cards. The ? card means “no idea”. The card with the coffee cup means “I want a break”.

Everyone has to Think

Using the cards forces everyone to think the task through themselves. It is no longer possible to be the last one to talk and simply repeat what others have said. Even though I’ve been careful to give everyone room to think for themselves in the past, I’m sure that people have changed their mind or made a final decision between to possible choices based on what others have said. The cards also force everyone to make a definitive decision. It is no longer possible to be vague.

I think it’s somewhere between 8 and 13, but it could be longer.

I’ve heard it many times and I’ve occasionally said it myself. The deck of cards sets an effective stop to that. There is no “maybe 8, maybe 13 card”. One single card has to be chosen. Either chose  8 or chose 13.

Everyone is the First

The idea with the deck of cards is that everyone show their cards at once. Everyone reveals their estimate on a clean table, without having to relate to what others have said. When planning without cards and being the last to tell what I think, I always tell my initial estimate that I decided on before being biased by the others’ opinions.

Still I’ve always taken into account what they said. If we’re all agreed I’ve spoken out my estimate with confidence. If I disagree with one or more of the others, I’ve sometimes been defensive and careful to not criticize. Sometimes when I’m the most senior in the room I’ve instead taken the role of a teacher who gently but yet definitely delivers the correct answer.

Using the cards was a relief. I could simply show my estimate without risking the independency of the others’ estimates and without having to carefully formulate my estimates based on what the others have said.

With the deck of cards everyone gets the advantages of being the first and everyone gets the advantage of being the last.

The Best Sprint Planning Ever

When we finished the sprint planning meeting we all agreed that this was our best sprint plan ever. We have had fun, laughing at any differences. We moved the focus to what to do insted of the actual estimate. Last, but not least, we left the meeting as a stronger team, having a collective ownership of the sprint backlog and the estimates.

I’ve handed back the borrowed deck of cards, but next week I’ll order a set for myself. I don’t think I’ll ever have another sprint planning without a deck of cards. It was too much fun and the effect on the team spirit was too large to be ignored.

This post is part of the Scrum series.<< Requirements in ScrumTest and Verification in Scrum >>

  • Albin Sunnanbo on 2012-04-05

    The deck of cards are really good (although I have only used cards branded by a competing consulting firm).

    The most rewarding part is when the team members have very different estimates, you often find that someone has thought of something that the others have forgotten, like “this also affects module, x, y and z.” or “with a simple twist we can reuse the module foo we wrote last sprint, won’t take more than half a day or so.”

    You also need to agree on the time unit on the cards. I have used the quite odd unit “half a day” and found it mentally easy to map quantity of work to that unit.

    I have also used the rule that if the estimate exceeds one week of work the task is declared invalid and to broad in the description. Such tasks needs to be broken down further before they can be estimated. My experience is that if you can’t break down the task more than that the requirements are not clear enough to be usable.

Software Development is a Job – Coding is a Passion

I'm Anders Abel, a systems architect and developer working for Kentor in Stockholm, Sweden.

profile for Anders Abel at Stack Overflow, Q&A for professional and enthusiast programmers

The complete code for all posts is available on GitHub.

Popular Posts

Archives

Series

Powered by WordPress with the Passion for Coding theme.