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.


  • Mac

    I agree with most everything here, I think another common pitfall is confuse velocity derived from these activities as a productivity metric.

    I do have a question prompted by the idea of only sizing enough for the upcoming Sprint. How do Story Points relate to velocity and is velocity a team only concern?

    • Mac, Thanks for your questions. I agree that when velocity is used as a productivity metric it can demotivate a team, especially when team velocity is used to compare teams. Generally, velocity is intended for use by the team to help them understand how much work they can complete within their cycle. Teams can also use the velocity metric to show patterns of capacity over time.

      Average velocity over the past 3 – 5 cycles is useful in predicting when a set of work might be completed. For example, if the team has established an average velocity of 20 points a cycle and there are 100 points of work to be completed, you can expect that approximately 5 cycles will be needed to complete the known work. I prefer to build slack into any longer term estimates and to say that 6 cycles are needed to complete the work in this example.

      The challenge is always around the unknown, Teams discover things about their work each cycle and it seems to be the norm that work grows over time. The real solution is to manage the committed work by delivering the most valuable items first. I hope this response was useful.

      Linda

  • Brandyn Harvey

    I was just recently introduced to the concept of Agile and planning poker and thus have limited knowledge on the subject. A few days ago, I went through the act of trying to agree on the “size” of a set of user stories with a team. It was fun and the discussions that were generated helped us understand the story from different perspectives. However, I noticed that through the process, those that exhibited less knowledge and experience on a subject practically defaulted in the next round to the numbers that those with knowledge and experience chose. Is this a common natural tendency for all Agile teams? If so, I would think that the last bad practice you list of adding points based on domain would also be a natural occurrence. Even if it wasn’t expressly laid out that way, wouldn’t it happen on its own just by other team members agreeing with the “experts”? How would you avoid this?

    • Brandyn, You are a good observer of human behavior! It is not uncommon for members of the team who consider others more experienced to defer to their teammates when sizing. This behavior is often exhibited by someone new to an established team. From my experience, as long as the conversation is taking place that creates a shared understanding of the story, then deferring to more experienced team members is not a problem. After team members gain experience using planning poker things should become more evenly distributed.

      When it comes to summing points from various domains to arrive at a cumulative number, this behavior should be managed by the facilitator, generally the ScrumMaster. Three points for development plus 5 points for testing do not equal an eight point story. It is important to discuss why a team member is sizing a story and be sure to ask if they are including the full effort of the story. It is not unusual for a team to size based on complexity of coding and forget to include analysis or testing. Good facilitation skills and a clear understanding of how to use planning poker are essential to a good outcome.

      Within a few rounds of planning you should see other patterns of story complexity surfacing for the team. Be sure to use the team retrospective to reflect on the original size of the story and compare it to the teams experience. Note that it is normal to find that the team’s experience working on the story can vary widely. It’s all part of the learning experience.

  • Sarah Statz

    Well said. I agree with your statement on not sizing too many stories at one time, however, if you are using a release burn down you do need all the user stories in your release sized for forecasting. I generally would setup 30 minute planning poker sessions every week until we had the release sized out. Depending on the size of the release backlog sometimes you’d need a few 60 minute sessions in the beginning to get through it all.
    Looking a few months deep into a backlog on occasion also helps you find those really big 80 or 100 point user stories that need a lot more breaking down and refinement. Of course, it’s all a balancing act.

    • Sarah, you bring up an interesting point. I agree that as a part of release planning, teams need to size stories that are several sprints ahead. Hosting short story review sessions can help lessen the overall burden of sizing stories for a large release. I generally recommend that if team’s need to plan out a large release, the stories are sized for no more than 4 sprints ahead. Further, I recommend that slack be built into the story slotting into sprints. I suggest they plan Sprint 1 at 100% of capacity, sprint 2 at no more than 80% of capacity, and sprints 3 & 4 are slotted with approximately 50% of the team’s capacity. This approach allows for the inevitable changes that occur over time, whether it is from something the team learned in a recent sprint, or business pivots on story priority. The larger stories or epics can be the riskiest to size as the larger a story gets, the less the team understand about it. Thanks for sharing your thoughts on story sizing!