Stefan Wolpers November 24, 2021 TL; DR: Ignoring the Capacity Check during Sprint Planning
There are plenty of failure possibilities with Scrum. Since Scrum is an intentionally incomplete framework with a reasonable yet short “manual,” this effect should not surprise anyone. For example, the Developers are ignoring a capacity check during the Sprint Planning, and as a result, the Scrum team creates a Sprint Goal that most likely cannot be accomplished.
Join me and delve into the effects of this trust-shattering practice in less than 80 seconds.
The Scrum Guide on Capacity Planning
Let’s refresh our memories regarding the Sprint Planning, the capacity check, and what amount of work might be accomplished:
Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts.
Source: The Scrum Guide on the Scrum team.
Unsurprisingly, the Scrum Guide points at the benefits of Scrum teams knowing their capacity in the upcoming Sprint. However, as Scrum teams are self-managing and comprise capable individuals, the Scrum Guide does not require a capacity check to become a part of the Sprint Planning.
The Effects of Ignoring the Capacity Check during Sprint Planning
The Problem: Before the Sprint Planning, the Developers failed to identify their capacity for the upcoming Sprint, resulting in less-informed creation of the Sprint Goal. There are various reasons why the capacity of the Scrum team is not constant but highly volatile, for example:
- Public holidays fall into the Sprint period
- Team members are on sick-leave
- Team members take personal time off
- Experienced team members have left the Scrum team
- New team members need to be onboarded
- Life interferes in an unpredictable way, for example, in form of a food-poisoning causing Tiramisù.
The Consequences: The consequences of failing to identify the available capacity may result in a too cautious approach in creating Sprint Goals—better safe than sorry, right? (Speaking of which, everyone will notice this approach, and it won’t work in the team’s favor.) Alternatively, the Scrum team may become too ambitious in setting a Sprint Goal and will most likely disappoint stakeholders by not delivering accordingly. (Given the importance of trust and that delivering valuable Increments regularly is the best way to create trust among stakeholders, the consequence of the latter is far from being trivial.)
The Solution: Take five minutes during the Sprint Planning and create a shared understanding of who will be available when. Risk-mitigation for Scrum teams has never been simpler.
Ignoring the Capacity Check during Sprint Planning — Conclusion
Permanently underdelivering, overcommitment, failure to accomplish the Sprint Goal, creating spillovers — all of this is sending a false signal to stakeholders. If these patterns happen to manifest themselves regularly, they will produce a massive trust issue very likely to impede your team’s collaboration with its stakeholders. Please remember: reliable delivery of valuable Increments is the #1 request from stakeholders. Do not put your Scrum team in harm’s way out of mere stupidity.
Is your Scrum team also ignoring the capacity check during Sprint Planning? Please share your learnings with us in the comments.
Business & Finance Articles on Business 2 Community
(70)
