The 5 Most Common Pitfalls of the Scrum Events
Barry Overeem
Co-founder The Liberators & Columinity: a product to improve teams and organizations through conversations based on data and scientific insights 🚀
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!
Visualization created by Nomad8
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 to 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.
Senior Software Developer | Engineer | Architect
9yI would add another one: using scrum as a silver bullet for all the projects because it's a hype and sells good.
Specialising in Digital Product Delivery, and Agile Transformations, across numerous business sectors.
9yAs for handling production interrupts mid sprint, there's many ways of doing this, but they depend upon your specific context: The team, the technologies, the quality of the code base, the management desires, the frequency of interrupts, etc, etc. As a general rule, I would suggest: Creating a story for each production interrupt. Timebox the story pint size instead of Estimating. Have the Product Owner swap a story(ies) from the Sprint Plan that have the same timeboxed story points, in favour of this new Interrupt Story. As a team, track how many stories and how many story points are being spent on interrupts, per Sprint and per Release. This will help the team, Management, and stakeholders decide if a different approach is needed.
Specialising in Digital Product Delivery, and Agile Transformations, across numerous business sectors.
9yMohammad Iftekharul Anam (CSM), Over committing on the Sprint plan is OK, if the team use Velocity to change what amount of work is committed in the next Sprint. E.g. Sprint 1 forecast 30 points worth of stories to do but achieved 26 points of stories Done. Sprint 2, forecast 26 points worth of Stories to do but achieved 24 points of stories Done Sprint 3, forecast 24 points worth of stories to do but achieved 28 points of stories Done If you track forecasted and achieved story points, it should have peaks and troughs. It should look like a heartbeat. This is healthy. If the forecast is always the same as the achieved, it's flatlined. The team are 'gaming' the plan to always 'be right'. This is an unfortunate anti pattern.
AWS Certified Solution Architect | Certified Scrum Product Owner® | Certified ScrumMaster®
9yOne other common challenge I have faced is teams making over-commitment on the sprint plan. Another challenge is having right amount of allocation for handling post-production issues while working on already implemented product. This list certainly is a good guide for SMs & POs to have in mind while managing scrum delivery :)
Co-creator of The Flow System™ | No Way Out Podcast Co-Host | AGLX NA MD
9yPlease explain why using the same retrospective format is a common pitfall? I would argue that using the same ineffective retrospective format is a common pitfall.