Planning Poker Reduces Risk and Waste

There are three particularly valuable things that can happen during a Planning Poker session. They may also happen during any flavor of estimation meeting, but seem to be more likely when using Planning Poker.

The Bigger They Are, The Harder They Fall

I recommend that you never use a story size greater than 13. Most stories that are estimated at 8 points or above can be split into smaller stories. You should always be looking for opportunities to break larger stories into smaller stories. If you have an 8 point or larger user story, it is probably actually two or more stories in disguise. The bigger the story, the more likely your estimates are wrong and the more likely that you have many smaller stories masquerading as one large story.

For instance, you may find that a story that originally looked like a 20 point story was really two 8 point stories, one 5 point story and 2 three point stories for a total of 27 story points. Better to break that huge story down into its five constituent stories and estimate them each individually.

But remember, a story is only a story if it provides value to the user. Splitting a story up into “As a user I want the backend for X” and “As a user I want all of the UI for X” is not the right way to go. If you can’t create smaller stories that still provide user value, then the story is already as small as you currently know how to make it.

Know When to Walk Away

You may realize while discussing a story that the story contains a big unknown, something that feels like it won’t be resolved during the implementation of that story. In that case it is best to split the story up into a research story and the story itself. For instance, “As a developer I want to know how to XYZ.” That way, if you never do figure out how to do the unknown part, you haven’t invested any effort into the overall story. This technique should only be used as a last resort, but it is much better to do this than to know going in that there is a big unknown and have to pull the whole story out near the end of the iteration.

Know When to Fold’em

Lastly, you may decide that you just don’t have enough information to estimate a story. In that case, you should have a mechanism for informing the product owner such as marking the story “need more info.” There’s no point spending time on estimation if there is insufficient information to do so. You’ll just be glossing over the problem and producing a false sense of security.

Breaking out research stories and kicking stories back to the product owner may seem like procrastinating, but it tends to build good habits. It keeps the team from committing to work that includes research projects, clearly defining some stories as research stories, and keeping the product owner on his or her toes.

Counting Your Chips

In summary, if you are mostly working on small user stories that have end user value, you are reducing the chance that you are putting something into the product that never gets used and you are also reducing the chance of starting work on something that never gets finished or has to be discontinued part of the way through. The smaller your stories, the smaller your risk and the less effort you’ve wasted when you run into problems.



See Also: "The Five Essential Ingredients of Great Agile Estimation"