Non-developers controlling the Sprint Backlog is like passengers grabbing the wheel: doubly detrimental by misguiding the direction and diverting the focus.
The Developers own the Sprint Backlog; they use it to guide their work towards the Sprint Goal. However, the nuances of this ownership reflect a broader conversation about autonomy and collaboration within Scrum.
While Developers exclusively own the Sprint Backlog, using it strategically to achieve the Sprint Goal, ownership disputes typically arise only in confrontational scenarios. Such issues should seldom occur in well-functioning Scrum teams, where all members fulfill their roles effectively.
“Developers are always accountable for […] Adapting their plan each day toward the Sprint Goal”
- Scrum Guide
The Sprint Goal should matter to everyone involved, not just the developers.
“The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.”
- Scrum Guide
Ultimately, adding stories to the Sprint Backlog should hinge on their alignment with the Sprint Goal. If work items don’t contribute directly, there must be compelling reasons why the Developers should not defer them to the next Sprint Planning.
Certainly, emergencies require immediate attention, such as a downed ordering website halting customer transactions. Developers cannot overlook these critial ourtages for the Sprint Goal. However, shifting focus from our primary objective to minor, non-critical requests, even from influential stakeholders, undermines our strategic priorities.
Teaching my teenage daughter to drive was one of the most nerve-wracking experiences of my life, and I doubt she recalls it any more fondly. This anxiety seems universal; my husband still gets agitated recounting his first driving lessons with his mom. The exact cause remains a mystery—whether it was her experience or a misjudgment from the passenger’s perspective—but she instinctively grabbed the wheel to steer for him.
Despite his inexperience, he had the presence of mind to wrestle the wheel from her, averting the very collision she believed she was preventing.
Not all Scrum Teams possess the courage and confidence to safeguard their autonomy against well-intentioned leadership intrusions.
This situation brings to mind one of the core Agile principles:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
- Agile Manifesto
Additionally, the Scrum Value of Respect aligns with this principle and holds relevance in this context.
“Scrum Team members respect each other to be capable, independent people, and are respected as such by the people with whom they work.”
- Scrum Guide
According to Scrum rules, if the Product Owner, Scrum Master, or a stakeholder suggests additions to the Sprint Backlog, it ultimately rests with the Developers to decide on the appropriateness of these suggestions. Their judgment deserves our respect and trust in their ability to deliver.
The wording in the current Scrum Guide supports the fact that the Developers own the Sprint Backlog.
“The Sprint Backlog is a plan by and for the Developers.”
However, for further clarity, the November 2017 version of the Scrum Guide provides more explicit guidance on this matter.
“Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.”
The softening of the language in the 2020 Scrum Guide revisions doesn’t suggest that Developers no longer own the Sprint Backlog. These changes, including the introduction of commitments for each artifact and shifting from “Development Team” to “Developers,” aimed to enhance collaboration within Scrum Teams and reduce the “us vs. them” mentality, not to alter ownership of the Sprint Backlog.
The product owner cannot directly change the Sprint Backlog. Still, they might negotiate with the Developers to collaboratively make adjustments that are more likely to get them closer to the Sprint Goal.
There is no day in which the Product Owner has authority over the Sprint Backlog. Their role in prioritizing the Product Backlog influences the selection of items during Sprint Planning and contributes to developing the Sprint Goal alongside the Scrum Team. This goal guides Developers in selecting Product Backlog Items for the Sprint Backlog, marking the extent of the Product Owner’s involvement with it.
The Developers are responsible for sizing Product Backlog Items to facilitate realistic forecasts in Sprint Planning. However, if you’re updating task estimates post Sprint Planning, this isn’t a core part of Scrum.
“The Developers who will be doing the work are responsible for the sizing.”
- Scrum Guide
After the Sprint has started, I’d ponder the benefits of re-estimating user stories. If a team member sees value in this task, it logically falls to them to take responsibility for it.
The Scrum Master does not own the Sprint Backlog; this responsibility lies with the Development Team, who actively manage and update it as they work towards the Sprint Goal.
Only the Developers can add stories to the Sprint Backlog. Those wanting to change the Sprint Backlog can do so by trying to convince the Developers.
The Sprint is like a road trip where the Developers drive the car towards our destination - the Sprint Goal. It’s unsafe for passengers to grab the steering wheel while in motion, just as it’s not helpful when people who aren’t Developers try to take over their job.
Letting the developers drive, with everyone else supporting, means we’re more likely to reach our destination as planned. It’s all about trusting the drivers to do their job while everyone else focuses on their role.
Quick Links
Legal Stuff