Can the Product Owner Change the Sprint Backlog?

Published

One of the long-standing myths among agilists is that the Sprint Backlog can’t change during an active sprint. 

Once it has been agreed on between the Product Owner and the Developers in the Sprint Planning event, some folks say, the Sprint Backlog can no longer change and should remain as-is until the end of the sprint.

In this post, I’m going to share my opinion on why that’s not necessarily true. After all, an agile approach to building products is about welcoming change in requirements, even late in development. The important thing is in how you welcome and manage the change.

So, can the Product Owner change the Sprint Backlog?

If circumstances change during an active sprint and the Sprint Backlog is no longer a good enough plan for achieving the Sprint Goal, the Developers can renegotiate the Sprint Backlog with the Product owner (and vise versa). As the person accountable to maximize the value of the team’s work, the Product Owner has the final say on changes to the Sprint Backlog. If the Sprint Goal becomes obsolete, the Product Owner can cancel the sprint.

One thing most members of the agile community don’t know about Jeff Sutherland, one of the 17 signatories of the Agile Manifesto and of the two co-creators of Scrum, is that, before he embarked on a career in IT, he used to be a fighter pilot. 

In one of Sutherland’s talks about Scrum, Sutherland likened a Scrum Team’s use of the framework to how a fighter pilot lands a plane.

The goal, he said, was always clear; to land the plane on the runway and have it come to a complete halt before he ran out of track. The plan, on the other hand, would change on every descent. The pilot had to intuit signals from the plane and its surroundings, and take action on the feedback for the plane’s approach and the weather conditions. This plan is never perfect and predictable; instead, it’s approximate and emerging.

Think of a sprint in similar terms. The Scrum Team is flying a plane (building the product). The team needs a runway (Sprint Goal) to land on. If that runway is no longer there, they abort the landing and move to the closest one.

The Scrum Team can come up with the best flight plan (Sprint Backlog) and forecast as accurately as they can how their descent and approach to the runway could look like. But when they get to land, the likelihood is that they’ll face crosswinds (change) and need to react (inspect & adapt) along the way. 

Whenever that happens, the Scrum Team is essentially confronted with two options (and has to make a choice; either option is possible):

  1. Stick to the original flight plan (Sprint Backlog), but risk to run out of runway or steer sideways onto the grass (deliver less value since their Sprint Backlog is now leading them further away—and not closer to—from the Sprint Goal);
  2. Inspect and adapt the plan (Sprint Backlog), as to land on the runway by course-correcting based on the feedback they’re getting (meet the Sprint Goal inspection and adaptation when new information is attained).

If you were in their situation, which option would you choose (and why)? 

Let me, and the rest of this post’s readers, know in the comments below.

When Can the Sprint Backlog Change?

If, in the course of the sprint, the Scrum Team identifies that the Sprint Backlog will no longer help them to meet the Sprint Goal, the Developers and Product Owner can inspect and adapt the scope, negotiating the change based on what’s best to do technically and what is of higher value.

As a whole, a Scrum Team and its stakeholders work to create a steady cadence and a sustainable pace of delivery. However, when circumstances change or original assumptions turn out to no longer be relevant, the Sprint Backlog can become less or no longer useful for the team in helping them meet the Sprint Goal.

In situations like these, the high-performing Scrum Team does what it does best. Its members inspect the Sprint Backlog and adapt it to respond to the new situation or based on the lessons they’ve learned. At the end of the day, a Sprint Backlog is just a plan that helps the Developers on the team to meet the Sprint Goal. 

As they say in the army, “no battle plan survives first contact with the enemy.”

Who Can Change the Sprint Backlog?

This is a question of much debate in the agile community.

In my view, the Product Owner has the final say on what goes in and out of the Product and Sprint Backlogs as the person ultimately accountable for maximizing the value of the work that the Scrum Team is doing.

Others are approaching this differently and saying that only the Developers in a team can change the Sprint Backlog. To me, this is a siloed and dangerous way to look at things, because it draws a line between the Product Owner and Developers. 

Ultimately, the Product Owner and the Developers are working in one team and building a single product. No leader, sponsor, manager, customer, or user is going to look at an Increment that doesn’t really create value and blame a single person in the Scrum Team for this.

A Scrum Team succeeds as a team and fails as a team. It does things well as a team and makes mistakes as a team. To succeed/fail well and make mistakes as well as doing things right, the people in the team need to communicate and collaborate based on the three pillars and five values of Scrum.

Here’s the thing… 

The Product Owner is ultimately accountable for the value delivered by the team and has the final say on changes to the work items in the Product and Sprint Backlogs. However, they can (and should) choose to delegate much of the responsibility behind that accountability to the Developers in their Scrum Team.

Ideally, the Product Owner is there to make decisions before the start of a sprint and make trade-offs when a change could be impactful to the team’s ability to meet the Sprint Goal during the course of the sprint.

What to Do When the Sprint Goal Becomes Obsolete?

The Product Owner can choose to cancel an active sprint if, for one reason or another and over the course of the sprint, the Sprint Goal becomes obsolete. Before doing so, they should advise with their Scrum Master and the Developers in the Scrum Team. 

When a sprint is cancelled, all finished work is reviewed, and all unfinished work is re-estimated and placed back in the Product Backlog. Cancelling a sprint is rare and the reasons why it can happen are very specific to the product, Scrum Team, and their stakeholders.

In other words, there are no rules or best practices for how to navigate yourself out of a sprint cancellation. You and your teammates are in uncharted territory and will have to find your own way to the best of your judgement. My best advice is to think rational and act practical. Some of the work that’s finished may be useful; find a way to use it. Don’t hesitate to throw away the aspects of the work that are no longer relevant.

The Bottom Line

Agile and the Scrum framework enable a team to work in iterative and incremental ways. As a benefit of that way of work, the Scrum Team maximizes their delivery of value and controls change effectively by anticipating it and responding to it as it (inevitably) happens.

So where do you draw the line? A good place to start is the Sprint Goal.

As long as the Sprint Goal is not obsolete, the Scrum Team can choose to inspect and adapt the Sprint Backlog if and when they come across unforeseen circumstances or new information along the way. In the rare (but possible) cases when the Sprint Goal becomes obsolete, the Scrum Team can cancel their sprint.

The Product Owner is ultimately accountable for maximizing the value of the Scrum Team’s work, which is why he/she has the final say on changes to the Product and Sprint Backlogs, as well as on whether or not a sprint should be cancelled. However, they can choose to delegate much of the responsibility of that to the team, while remaining accountable to their choices.

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.