Before you start debating story points vs. 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 Scrum Master experiments with the process of Planning Poker before they have personal experience in how the tool should be used. Scrum Masters 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 Scrum Masters 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 from thinking independently.
One of the worst experiences 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 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.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
