Pitfalls of Planning Poker

Added to Process

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

About the Author

Linda Cook, a recognized technology leader and Agile Transformation expert, is committed to helping organizations achieve their strategic goals. With over 21 years of experience as an IT executive, Linda offers a unique blend of leadership, innovation, and vision which allows her to tackle the most complex organizational challenges. She currently leads a Lean/Agile consulting practice for Project Cooks, LLC. Formerly an Agile Program Leader at PayPal, Linda managed the company’s largest IT initiative with over five hundred staff across fifty-seven teams located in four countries. Prior to holding this position, Linda led several Lean/Agile transformations for large organizations, including Fortune 100 companies, and generated team performance improvements up to 250 percent. She has also managed several large-scale system development efforts and led multiple Agile programs through successful ISO 9001-2008 audits and CMMI appraisals. Linda is a passionate contributor to Agile non-profit organizations. She is a board member and the treasurer of the Agile Alliance and has played an instrumental role in establishing the Agile Alliance chapter in Brazil. Linda also served on the board of the Agile Leadership Network from 2010 through 2013 and chaired the organization’s national conferences, including Houston, Texas in 2011. Linda frequently speaks at Agile events around the world on topics ranging from the Future of Agile to Agile Release Planning. Linda received a bachelor’s degree in business management from the College of Notre Dame with a concentration in computer information systems. She has also completed post-graduate courses in transformative leadership at Maryland University of Integrative Health. When not focused on building teams and great software, Linda enjoys country living and raising horses. Currently based in Maryland, USA.


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.