February 29, 2016
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
- Using an everlasting Sprint 0 before the "real" Sprints can start
- Continuously changing the Sprint rhythm
- Extending the Sprint with a couple of days to ensure a "done" Sprint
- Using a hardening sprint to tie up the loose ends identified during earlier sprints
- Not having the same Sprint rhythm, when working with multiple teams on the same product
Pitfalls of the Sprint Planning
- Having a Product Owner who doesn't have a Sprint Goal in mind
- Using a Product Backlog that isn't refined enough
- Not knowing the velocity and upcoming capacity of the Development Team
- Not taking the Definition of Done into account when crafting the Sprint plan
- Ending the Sprint Planning without a shared commitment on the Sprint plan and its goals
Pitfalls of the Daily Scrum
- Not doing the "Daily" Scrum every day
- Considering the Daily Scrum as a status-update towards the Scrum Master
- Not having a shared and clear Sprint Goal as the main indicator
- Focus on detailed activities instead on the actual results the team has achieved
- Not updating the Sprint Backlog during the Daily Scrum
Pitfalls of the Sprint Review
- Considering the Sprint Review only as a demo
- Demonstrating the results to the Product Owner, instead to the stakeholders
- Not inviting any stakeholders and hereby neglecting gathering feedback on the increment, Sprint and Product Backlog
- Cancelling the Sprint Review because "there's is nothing to demonstrate"
- Don't letting the Development Team attent the Sprint Review because they've got more important stuff to do
Pitfalls of the Sprint Retrospective
- Cancelling the Sprint Retrospective because "there's nothing the improve"
- Cancelling the Sprint Retrospective because "we don't have enough time to improve"
- Using the same format over and over again
- Having far too much ambiguously defined improvements as a result
- Not having any committed improvements with a clear plan of approach for the upcoming Sprint
Pitfalls of Backlog Refinement
- Doing not enough Backlog Refinement, which results in a low quality Product Backlog with lots of ambiguity
- Doing too much Backlog Refinement, which results in a far too much detailed Product Backlog
- Considering Backlog Refinement as an activity that includes only the Product Owner and the "Lead Developer"
- Considering Backlog Refinement as too expensive to spend 10% of the teams capacity on
- 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.