by Jake Worth on April 9, 2019

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 feels like they own the result.

This technique is a variant of planning poker; read up 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 correspond to the number 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 point 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?

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 to 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