24 Common Scrum Pitfalls Summarized

Scrum is the most popular agile method… if you count all of the teams doing “Scrum Butt”.  Doing Scrum really well is much harder and much rarer.  Here is a list of 24 common Scrum pitfalls or bad behaviours of Scrum teams:

  1. Excessive Preparation/Planning: Regular big up-front planning is not necessary with Scrum.  Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans.  Even the Product Backlog can be created after the first Sprint has started.  Read more about the Excessive Preparation  Scrum Pitfall here.
  2. Focus On Tools: Many organizations try to find an electronic tool to help them manage the Scrum Process… before they even know how to do Scrum well!  Use manual and paper-based tracking for early Scrum use since it is easiest to get started.  Finding a tool is usually just an obstacle to getting started.  (And besides, check out what the Agile Manifesto says about tools.)  Read more about the Focus On Tools Scrum Pitfall here.
  3. Problem-Solving in the Daily Scrum: The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised.  Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested.  The ScrumMaster facilitates this meeting to keep it on track.  Read more about the Problem-Solving in the Daily Scrum pitfall here.
  4. Assigning Tasks: Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should assign tasks to team members.  It is better to wait for someone to step up than to “take over” and assign a task.  Read more about the Assigning Tasks pitfall here.
  5. Failed Sprint Restart: Although cancelling a Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting.  Teams should immediately re-start after cancelling a Sprint.  Read more about failing to re-start a cancelled Sprint here.
  6. ScrumMaster As Contributor: The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle.  Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions.  Read more about the problems of having a ScrumMaster as contributor here.
  7. Product Owner Doesn’t Show: The Product Owner is a full member of the team and should be present at all Scrum meetings (Planning, Review and Daily Scrums).  As well, the Product Owner should also be available during work time.  Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.  Read more about the pitfall of the Product Owner not showing up.
  8. Stretch Goals: The team decides on how much work it will do in a Sprint.  No one should bring pressure on the team to over-commit.  This simply builds resentment, distrust and encourages low-quality work.  That said, of course teams can be inspired by challenging overall project or product goals.  Read more about the pitfall of setting stretch goals for Scrum teams.
  9. Individual Heroics: Individuals on a Scrum team should not do excessive individual overtime, or in any other way try to be the “hero” of the team.  Scrum helps us build great teams of people, not teams of great people (quote from Barry Turner).
  10. Team Organizes Product Backlog: The team does not have proper insight into the needs of users and instead should be focused on solving technical problems.  The Product Owner needs to be accountable for ROI and therefore should resist any pressure from the team to do things in a particular order for “technical” reasons.
  11. Product Owner Specifies Solutions: The Product Owner must allow the team full freedom to come up with solutions to the problems presented in the Product Backlog.  PBIs should be free of technical specifications unless they can be tied directly to a customer or end-user request.
  12. Urgent Interruptions: Urgent interruptions should not be allowed in a Sprint… instead, if it is urgent enough, the team should cancel the Sprint.  Otherwise, the interruption should be put on the Product Backlog and deferred until the start of the next Sprint.
  13. Making Assumptions: Often team members will fail to ask the Product Owner about details of the work they are doing.  A team member solves problems, but it is critical to know about constraints.  The feedback between PO and Team Member should be ongoing throughout every day of the Sprint.
  14. Not Getting Done: This is hard to prevent from happening from time to time, but it can become a habit for a team to over-commit.  Make sure that a team that is doing this is using burndown charts effectively and is holding demos even when they have not completed all their work.
  15. Demo Not Ready: Sometimes a team forgets that it will take time to prepare for a demo: cleaning the team space, setting up a demonstration environment, getting scripts ready, and ensuring that critical stakeholders are prepped.  These activities can be part of the tasks in the Sprint Backlog.
  16. Prototype Not Shippable: A Scrum team should attempt to produce production-quality, “potentially shippable” software right from the very first Sprint.  Building prototype code just delays the inevitable need to write production code.  Similarly, wireframes, detailed designs and other similar tools should also be avoided.
  17. Distributed Team: Although Scrum does not officially require team members to be collocated in a “war room”, the reality is that any distribution of team members (even just into separate cubicles) has a huge negative impact on transparency and communication, which in turn has a huge impact on productivity and quality.  Here is a YouTube video on distributed Scrum teams.
  18. Directive ScrumMaster: The ScrumMaster needs to be a facilitator who supports the team in learning self-organization, and the Scrum rules.  The ScrumMaster should never succumb to the temptation to suggest how a team member does his or her work, nor what task next to work on.
  19. Changing Team Membership: Scrum is a framework for creating high-performance product development teams.  If the membership of a Scrum team changes, it forces that team to re-start the Forming-Storming-Norming-Performing sequence.  If the team is in Norming or Performing, then changing team membership for any reason is a waste of quite an investment.  Here is a YouTube video on changing Team Membership.
  20. Non-Scrum Roles on the Scrum Team: It is very common for an organization to create a Scrum team without changing the official title and duties of the people who are members of that team.  For example, a person who is a Project Manager might be given the responsibilities of the Product Owner without an official change of title.  Scrum teams should only have a ScrumMaster, a Product Owner, and Team Members.  Our video about the roles on a Scrum team explains why!
  21. Giving Up On Quality: Scrum has very high demands on teams regarding the quality of their results: “potentially shippable software”.  It is easy for a team or organization to fall back on the crutch of defect tracking software instead of maintaining extremely high levels of quality at all times (due to pressure to release features).
  22. Imposed Deadline Scope And Resources: Scrum is reality-based.  If an external stakeholder wants to impose a minimum scope, a deadline and constrain the resources available to the team then they must allow that quality will slip… which in turn is against the principles of Scrum.  The reality is that no-one can predict the future so any such imposition is simply a fantasy.
  23. Definition of “Done” Imposed:  There is confusion between the concept of the definition of “done” and “standards”.  Managers and other stakeholders often incorrectly impose standards on a team as its definition of “done”.
  24. ScrumMaster Not Present: I once saw an organization that had created a room for a “team” of ScrumMasters.  They worked there together most of the time!  The only time the ScrumMaster should be away from the team is when he/she is working on removing an impediment that is outside the team.  Otherwise, the ScrumMaster should be in the team’s room.

Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!

46 thoughts on “24 Common Scrum Pitfalls Summarized”

    1. Hi Rafael, good question. Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demoed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.

      If I remember correctly, this is how the Federal Reserve Bank got started with Scrum almost a decade ago. It was part of Ken Schwaber’s stories about how to get started with Scrum by using the “agile skeleton”. The main point is to not make excuses for getting started on the continuous improvement process that Scrum sets in motion.

    2. This can be effective in a very particular case where developers know what is needed as well as the PO, and there is no set of features that are known beforehand.

      My initial reaction to that statement was fear that it can be interpreted as “I don’t need a Product Backlog at all, just discover it along the way during the Sprints” (I can think of some people who would), which can lead to a disaster.

    3. I agree! It is very important to have a Product Owner with a clear understanding of business value, and who prepares for the upcoming Sprint by creating a Product Backlog (or at least enough PBIs for the next Sprint or two).

    4. Hi Mishkin – Even in terms of just SCRUM I cannot see how the team can actually work without the Product Owner defining the priority etc… Your view of the team to just start with what they know of is not a good approach.
      DSDM-Atern Agile PM – will help in these situations. In Atern the initial 2 phases i.e. Feasibility and Foundations would help the Business see what the team (i.e. Project Manager, Technical Coordinator, Business Visionary (Product Owner in SCRUM)) is proposing and how the solution would be developed… So if the organisation follows Atern-Agile PM then there will never be a case where the SCRUM team looks orphan in the 1st sprint.

    5. Hi Vishal. Thanks for your thoughtful comment. One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog. Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt? This is actually a philosophical question (as well as a practical question). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.

  1. Very good summary and agree to nearly everything other than no.17… Principle says that distributed team wont work but I am part of an engagement where we have made it possible where nearly 9 to 10 projects have their teams distributed across continents and it works – as each project team (staff based across location) works on the same backlog, code base, sprint goal etc… we use good communication/collaboration tools (including AV) where the remote staff can join in the sprint planning, daily stand-ups, retrospectives and show and tells… And it works for us…

    1. Hi Vishal… of course it is possible to work with a distributed team. It doesn’t mean that it is a good idea. Distributed teams will always be more productive if those same people are co-located. Everything you do with AV collaboration tools is a poor substitute for the reality of face-to-face communication. There are a multitude of communication studies which unequivocally show this. It is irrelevant if you are using Scrum or any other method. This is why I mention that in the pitfall: Scrum does not officially require co-location. I will also admit that sometimes businesses have good strategic reasons for using distributed teams, but this must be done with full awareness of the costs involved.

  2. Excellent list,

    Some nits to pick…

    #7. PO doesn’t need to be at the daily Scrum. It’s nice, but not required. Daily scrum is for the development team to plan out the day’s activities.

    #15. Demo not Ready. Maybe it’s a semantic thing, but the Review is more then just a demo. Not Ready for the Review seems like more appropriate wording.

    #24. A good Scrum Master can work with more then one team, so sitting with “the Team” isn’t mandatory. Again, it may be preferred, but not necessarily a pitfall. But, if they are only working with a single development team, then yes, they should be in the same space.

    Again, excellent post!

    1. Hi Steve,

      Thanks for the (implied) questions.

      #7. The Product Owner is a full member of the Scrum Team. Historically, there was concern that the PO was a “chicken” but in fact they are a “pig”. As such, they need to be at every daily Scrum to share with their team members what they have done (with the product backlog), what they will do (with the product backlog) and what obstacles are in their way (because the SM has to help the PO too!) The updates on the Product Backlog are an essential part of the Product Owner being able to effectively groom the backlog.

      #15. I agree. Actually, I sometimes use “Demo” when I really should use “Review”. I think of demos as very hands-on with lots of great feedback, and effectively the same as UAT.

      #24. Strongly disagree. There are two aspects to this. First – the SM is a member of the team. It is almost impossible to be fully committed to two teams. Commitment is critical for the creation of high-performance teams. Sitting with the team is a sign of commitment. Sitting outside the team is a sign of lack of commitment. Second – the SM job is full time… just like being a fire-fighter. It is essential that the SM has some slack so that they can respond immediately to obstacles.

  3. Mishkin,

    This is a great compilation of pitfalls. Thank you for this contribution!

    Here are some others that come to mind:

    1) Picking what to adhere and not adhere to from the Agile Manifesto
    2) Management Team Deciding on What’s Best for Team vs. Team Deciding On What’s Best
    3) Team assumes mastery of Agile techniques after just a couple of sprints (a.k.a., team stops learning)
    4) Team performs techniques without seeking to understand why they are doing something
    5) Randomly changing sprint length, sprint after sprint
    6) Teams don’t understand the importance of commitment
    7) Teams short-changing the time for sprint retrospectives
    8 )Teams not understanding how to go about segmenting and delivering functionality
    9) Teams using the product backlog as a requirements management tool

  4. To add, for #8, using stretch goals virtually guarantees that the team can never succeed and will get in the habit of accepting failure. In Scrum, success is delivering all the stories in the commitment. And continuous improvement winds up being refinement of the team’s techniques for overcoming impediments to that kind of closure. Stretch goals, with their ambiguous commitment and ambiguous state of closure, undermine the power of Scrum. If the team has capacity nearing the end of sprint, it can always adopt work from the top of the product backlog.

  5. Hi,

    According to Scrum Guide, daily scrum is a meeting for the Development Team. So I can’t agree with #7. When You allow PO to participate in standups you change it to reports meetings very quickly.

    1. Hi Filip! Thanks for the comment. There is actually a lot of disagreement about this point among senior Scrum practitioners such as Certified Scrum Coaches and Certified Scrum Trainers. I will only say that excluding the PO and SM from the Daily Scrum meeting causes long-term problems if you are trying to create high-performance teams. Scrum originally was focused on this idea of high-performance teams and now is not so much. Instead it is really focused on just doing good product development. So, really, it’s a choice: do you want “good” product development or do you want “high-performance” teams?

  6. Very insightful and timely article. here are my 2 cents
    #1. This statement is a bit too generic and vague. After working with several Scrum teams by now, I see it turning into huge misunderstanding in regards to pre-planning. The scrum teams are not even planning their Sprints and start with poorly written stories with no supporting details at all. The result is that half of the stories in the Sprint remain incomplete because developers didn’t know how to approach a problem and testers didn’t know what to test
    #7. This is again a bad decision made by my org and the result is a new(and worse) form of command and control in the room. Product owners are automatically assuming the role of Project Manager instead of focusing on their primary role which is keeping a well groomed list of prioritized stories. Their decisions on processes are trumping Scrum Master’s and SM is becoming an order taker. Not-present PO is really not an issue if there is a good SM but an Over-present PO is a suicide for high performing/self managing team

    1. Hi Tam,

      Thanks for the comments! The #1 point is interesting. Based on experience, I see a broad range of things that “work”. However, point number one is really about the idea that most organizations still do big up-front budgeting, analysis, architecture, requirements, etc. The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [emphasis added]. I agree that there is a different extreme that some teams go to that has no planning – and that’s a bit more like Kanban. The two points you have made are actually related, however. The Product Owner is a full member of the Scrum Team and MUST be actively involved with the team throughout the Sprint. If developers and testers don’t know what they are doing, it means that the PO isn’t collaborating enough with the team throughout the Sprint. Again, I agree that it is possible for the PO to have a bad relationship with the rest of the team. However, the problems there should be solved through collaboration and the facilitation skills of the SM. This is a problem that could come from anywhere including other team members. It’s all the same problem and not unique to the role of the PO. Having an aggressive micro-managing Scrum Team member (PO or otherwise), is probably worse than having an absent PO. But both are problems that have to be addressed by the SM facilitating the creation of a high performance team that includes the PO.

  7. so this question might not be relevant for this post or it may be. But here it goes… how would you identify/differentiate between the scrum master impediments and team level impediments? what would be some examples. For e.g. we have some scrum master who raise concerns about not having enough testers in the team and they say its an impediment, but in my mind everyone in the team should be able to test ( cross functional team right !!!) so they should be coaching the team to swarm through the testing instead of requesting for more tester at the portfolio level. Any thoughts on this anyone??? and probably some examples (has anyone been facing similar issues?)

    1. Nick,

      Sorry for the delay in responding to your question. It’s a great question. The ScrumMaster should be helping the team resolve all impediments. However, the ScrumMaster has to use judgement, wisdom and some plain old common sense in dealing with those obstacles. A good ScrumMaster will also use tools like TRIZ for innovation, root cause analysis e.g. 5 Whys, and many retrospective techniques. Coaching, mentoring, influencing, and other communication skills including good listening all play an important role. Finally, the ScrumMaster should remember that a self-organizing team should be encouraged to solve as many technical problems locally as possible. In your specific example, if the team feels like it doesn’t have enough testers, then the ScrumMaster could legitimately challenge the team with the question: “what would you change so that the number of testers that the team has is sufficient and so that no more testers are needed?” This is an example of a powerful question – an important coaching technique.

      Also, one cautionary note: remember that a cross-functional team does not mean that every person on the team has the skill to do every activity. It means that all the skills (functions) necessary to complete a “done” increment of your product are present on the team in some degree. One person could have many skills – and this is encouraged – but it is not required.

  8. We run a scrum in our organisation, and its the biggest pile of bullshit going. Shuffling lists Its just micromanaging stuff.
    22 People in an IT team forming a single scrum, with hundreds of non related tasks. Its farcical.

    Be truly agile, respond to change and release small iterations of a product when ready. Don’t need burn down charts and 4 hour planning/review meetings

    Just remember that

    1. Hi Ian,

      Although less common, you have identified some pretty serious mis-applications of Scrum. I’m really sorry to hear that. For example, 22 people should never be on the same Scrum team, and hundreds of non-related tasks completely misses the point of the Scrum value of focus. You’re completely right: it is farcical!

      If you don’t mind, I would love to write another more in-depth article about the problems you are seeing… if you felt like telling us more about what is happening. You could also contact me directly. Good luck, in any case. I hope things get better.

  9. Hi Mishkin thank you for your response.
    There is perhaps too much to write here, and I have looked for your email address but I am unable to find it.

    Of course I don’t mind if you cover with an in-depth article,
    Companies like the one I work for might actually benefit from it if they can recognise their driving their staff insane and adjust it.

    1. Hi Ian, my email address is mishkin at berteig consulting dot com. I will write something up: it is in my backlog! If you feel like sending me more in an email I would be happy to consider the details in my writing.

  10. Hi,
    I strongly agree with the contents of this post. Thank you for the words of wisdom, that can seem obvious but at the same time can be so hard to actually embed. To me the whole point is to realise that building teams that get stuff done is far more important than attempting to optimise individuals, and to understand that the journey is a long but rewarding one.

  11. I have query. in a scrum team if one member of the team finishes of the task most of them times before time. And other team members are slow. What shud be done? If the task is redistributed after the team-member who finishes task early. That wud be line encouraging slow members not to finish task next time also. What should be the solution?

    1. Hello Ash, What does the team say about this matter in their retrospectives? Does the team perform any of the work as pairs or mobs — or are the team members always working individually?

  12. While i can agree that these are pitfalls to avoid within a scrum driven project, personally i see not doing about half of these points is detrimental. Try building a house using these methodologies. It’s funny how there are thousands upon thousands of posts, blogs, rants, etc. out there on the tubes from intelligent, experienced professionals disagreeing with these so called “better” trends and the respose usually made is “you’re doing it wrong” or “that’s waterfall”. Dogmatic belief system.

    1. I agree: I wouldn’t use Scrum to build a house. That’s not what Scrum is for! It would be like trying to pound in a screw with a hammer. And, you are also right that in some situations the things I’ve described here might be good.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.