Louis-Philippe Carignan — October 26, 2018 — October 26, 2018
I have an important favor to ask to Scrum practitioners who are asking their team to commit themselves to their sprint backlog at sprint planning.
If you do so, please stop.
The Scrum Guide doesn’t mention committing to work planned at sprint planning. Have a look. Please. Do a “Find” on the word commit (or commitment). It is not mentioned in the sprint planning section. It is only mentioned in the Scrum Values section.
Here are a few excerpts from the Scrum Guide about what we should do at the sprint planning
Excerpt #1
The Development Team works to forecast the functionality that will be developed during the Sprint
The Development Team forecast work. It doesn’t commit.
Excerpt #2
Only the Development Team can assess what it can accomplish over the upcoming Sprint.
The Development Team assess the work to be done. It doesn’t commit.
Excerpt #3
… the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.
The Sprint Goal is actually the North Star of the sprint. Use this as your guiding light on the work that needs to be accomplish. Here are a few examples of sprint goals that one of my team had lately:
- Sprint X: Build the authentication flow of the Slack bot.
- Sprint Y: Build the new help for Slack.
- Sprint Z: Build V1 for Outlook Add-in.
Now that we’ve move aside the C word, Scrum also offers a lot more flexibility around the unplanned work in the sprint. On that point, the Scrum Guide offers us the following guidance:
If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.
That’s right, the Development Team collaborates with the Product Owner to renegotiate the scope.
As our development teams are more and more DevOps, it is harder for them to commit on the exact work to do in a sprint. Outages. Bugs. Unplanned work from other teams. Those are a few examples of why forecasting makes more sense than committing to work.
If you’re in a DevOps team working on operational tasks at the same time as new features, Scrum is still a great framework to manage your complexity.
Business & Finance Articles on Business 2 Community
(41)
