The 5 Most Common Pitfalls of the Scrum Events

This week I facilitated a Scrum Master training in which we gathered the most common pitfalls of the Scrum events. It resulted in a nice overview with lots of recognizable pitfalls. In this blog post I'll share the results with you, completed with some ideas of my own. As you will see, it's only a brief description of the pitfalls. It doesn't contain detailed advice on how to deal with them. Currently I'm writing a white paper about the Scrum events, and for sure this will contain some practical advise on how to handle these pitfalls!

Pitfalls of the Sprint

1. Using an everlasting Sprint 0 before the "real" Sprints can start


2. Continuously changing the Sprint rhythm


3. Extending the Sprint with a couple of days to ensure a "done" Sprint


4. Using a hardening sprint to tie up the loose ends identified during earlier sprints


5. Not having the same Sprint rhythm, when working with multiple teams on the same product

Pitfalls of the Sprint Planning

1. Having a Product Owner who doesn't have a Sprint Goal in mind


2. Using a Product Backlog that isn't refined enough


3. Not knowing the velocity and upcoming capacity of the Development Team


4. Not taking the Definition of Done into account when crafting the Sprint plan


5. Ending the Sprint Planning without a shared commitment on the Sprint plan and its goals

Pitfalls of the Daily Scrum

1. Not doing the "Daily" Scrum every day


2. Considering the Daily Scrum as a status-update towards the Scrum Master


3. Not having a shared and clear Sprint Goal as the main indicator


4. Focus on detailed activities instead on the actual results the team has achieved


5. Not updating the Sprint Backlog during the Daily Scrum

Pitfalls of the Sprint Review

1. Considering the Sprint Review only as a demo


2. Demonstrating the results to the Product Owner, instead to the stakeholders


3. Not inviting any stakeholders and hereby neglecting gathering feedback on the increment, Sprint and Product Backlog


4. Cancelling the Sprint Review because "there's is nothing to demonstrate"


5. Don't letting the Development Team attent the Sprint Review because they've got more important stuff to do

Pitfalls of the Sprint Retrospective

1. Cancelling the Sprint Retrospective because "there's nothing the improve"


2. Cancelling the Sprint Retrospective because "we don't have enough time to improve"


3. Using the same format over and over again


4. Having far too much ambiguously defined improvements as a result


5. Not having any committed improvements with a clear plan of approach for the upcoming Sprint

Pitfalls of Backlog Refinement

1. Doing not enough Backlog Refinement, which results in a low quality Product Backlog with lots of ambiguity


2. Doing too much Backlog Refinement, which results in a far too much detailed Product Backlog


3. Considering Backlog Refinement as an activity that includes only the Product Owner and the "Lead Developer"


4. Considering Backlog Refinement as too expensive to spend 10% of the teams capacity on


5. Not involving any stakeholders to clarify specific parts of the Product Backlog

These are the top 5 pitfalls that were discussed during a recent Scrum Master training. Extended with some of my own ideas. Do you know any other common pitfalls? Please share them with me, I would highly appreciate it!

PS: I'm aware of the fact that Backlog Refinement isn't a Scrum event but an activity. But for the sake of completeness I've added it to this blog post.