What Capacity Check?
Avoid putting your Scrum team in harm’s way by ignoring a capacity check during Sprint Planning, endangering the Sprint Goal: Making Your Scrum Work #23.
Join the DZone community and get the full member experience.Join For Free
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.
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
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 food poisoning causing Tiramisù.
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.
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.
Permanently underdelivering, overcommitment, failure to accomplish the Sprint Goal, and creating spillovers all send 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.
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.