Planning Poker: Speed Mode

This post is by Hashrocket from Hashrocket

Click here to view on the original site: Original Post

Estimating stories is an important part of development. It helps
developers imagine the work ahead and stakeholders understand what can
be accomplished. On a recent project, my pair and I developed a technique for
estimating stories that I’d like to share in this post.


Estimating is hard. Perhaps some people in the story grooming meeting were
involved in an earlier estimation, and sense a conflict of interest. Others
have more context than everybody else, and their estimation is likely accurate.
Some might be pessimistic about a feature they don't understand, while others
maybe too optimistic for the same reason.

Add to this the dynamics of a group. New team members hesitate to speak up
about a story because they don't want to look, well, new. Seniors hesitate too
because they don't want to influence everybody else.

The result? Whoever speaks up wins, and pointing becomes like throwing darts.
Nobody like they own the result.

Planning Poker: Speed Mode

This technique is a variant of planning poker; read
on that technique if you're
not familiar. To summarize, planning poker is a gamified technique for estimating stories using playing cards, designed to find consensus by reducing the cognitive bias of anchoring.

The benefit of planning poker is that it can alleviate the problems described
above. But like any ceremony, it must be practiced. For a small team
moving quickly, that means keeping things simple.

A faster version of planning poker my pair and I used recently is inspired by the children's
game 'Rock Paper Scissors'. Here's how it works:

  • For each story, we read through the description, acceptance criteria,
    and comments. When we both feel like we understand the story, we move into
    the estimation.
  • We count to three and throw our hands out, showing a number between zero and
    eight. (Substitute this for the minimum and maximum points values in your
    estimation process). The numbers corresponds to the amount of points we each
    think the story is worth. We do it together so we don't influence each other.
  • If we agree, we assign the points and move on.
  • If we disagree, the person with a higher pointing explains their assessment. What complexity do they see that isn't obvious? Are they being
    realistic, or cautious?
  • When consensus is reached, the final pointing is recorded.

In a group larger than two, you might leave explanation duties to outlier
ratings. Did one person throw one point and most of the group throw four or
five? How are they arriving at one? Let's have a debate. Did
one person throw an eight and everyone else threw one or two? What are we
missing? Are they perhaps lacking context, or overestimating complexity?

"But I Don't Want to Talk!"

The price of this technique is the discomfort of having to vote on every story,
and sometimes defend yourself. Why is that worth it? Because the final point value is
important. Everybody's voice matters, and no one person should dominate the discussion.
It's in the spirit of the notion that "there are no dumb questions"; if you
don't understand something you aren't alone. Using a Rock Paper
Scissors-style technique forces marginalized opinions into the spotlight.

We can also use this process to inform our assignment of the work. Perhaps a person who ranked a
story at low value should be put on the story as an owner; they'll bring
expertise or confidence that will make the story move quickly. Perhaps the person who ranked
a story at a high value should also be put on the story. They're seeing edge
cases others don't see, or they might learn by working in an unfamiliar domain.
Getting those opinions out there in real-time helps us divvy up the work.


Estimating stories is an important part of preparing for development. It helps
developers imagine the work ahead, and helps stakeholders understand what can
be accomplished. I hope this technique is useful for other teams trying
estimate their work and move quickly.

How do you estimate stories? Have you ever used a modified version of
planning poker? Send us a note on Twitter.

Photo by Marcus Wallis on Unsplash


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.