Planning Poker

Before you start debating story points versus no estimates, let’s examine what can go wrong when a team uses Planning Poker® with Story Points to estimate their work.  The first misnomer is that Planning Poker is not an estimating tool.  It is a tool, that when properly applied can help a team size the effort needed to complete a user story.  Let’s begin using the term sizing for stories instead of estimating.

The pitfalls noted here are based on my personal experience coaching teams using Scrum with Planning Poker for over a decade.  Often time the trouble starts when a well-meaning ScrumMaster experiments with the process of Planning Poker before they have personal experience in how the tool should be used.  ScrumMasters often guide the team to the desired answer rather than let the team arrive at their answer based on conversation and understanding of the work.  Even worse, I have witnessed several ScrumMasters declaring the story point value once the story is read.

Planning Poker should introduce an element of fun and not become a source of dread during planning.   Another pitfall of Planning Poker occurs when team members are allowed to select their size one at a time.  This behavior encourages intimidation by more experienced team members and discourages others to think independently.

One of the worst experience you can have as a team is trying to size too many stories at one time.  If your team typically completes 10 stories a sprint, why would you size 20 or more stories in sprint planning? Sizing too many stories leads to fatigue and waste.

Yet another pitfall of Planning Poker occurs when teams are expected to size stories that lack appropriate acceptance criteria.  A long list of acceptance criteria can indicate a story that is too large to fit in a sprint.

Then there is the bad practice of adding points based on the domain when developers agree on how many points to design and code the story and then the testers add the points needed to complete testing.

Given the opportunity for challenges using Planning Poker, it’s not surprising to learn that many people have had poor experiences using this technique.  Follow me, Linda Cook, on to learn more about good techniques for use Scrum, including Planning Poker.