Skip to main content

Can Product Owner add/remove from Sprint Backlog?

Last post 08:47 am December 6, 2021 by Simon Mayer
9 replies
12:02 pm November 29, 2021

I thouht Sprint Backlog is entirely owned by Developer team and nobody else. Am I wrong?


08:29 pm November 30, 2021

From the Scrum Guide:

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.

Since the Sprint Backlog is the plan for the Sprint by and for the Developers, no one in the Product Owner capacity should be changing the Sprint Backlog. However, there's nothing in the Scrum Guide that prevents the Product Owner from also being a Developer.


10:40 pm November 30, 2021

The Product Owner should not be changing the Sprint Backlog.  The Developers change the Sprint Backlog.  If the Product Owner feels there is a need to change the Sprint Backlog, that should be discussed with the Developers. Even if the Product Owner is also a Developer, that does not give them permission to modify the Sprint Backlog at will. 

Notice in the quote that @Thomas Owens provided it says "...by and for the Developers." (plural not singular).   There is no single person that can update the Sprint Backlog according to their will. It needs to be an agreement made by all of the Developers.  This prevents any single developer from becoming the decision maker which is what many companies want to have. 


11:00 pm November 30, 2021

Can Product Owner add/remove from Sprint Backlog?

He or she can remove Product Backlog items from the Sprint Backlog by removing them from the Product Backlog.


07:17 am December 1, 2021

if removal or addition of items in the sprint backlog done without the knowledge or acceptance of the developers then that is to be fixed. As you know changes in the sprint backlog should not impact the sprint goal. If PO feels Sprint goal is not valid anymore, the sprint can be cancelled and start with new one.


09:54 pm December 3, 2021

Daniel and Ian, it seems you guys disagree?


10:56 pm December 3, 2021

No, we have differing opinions based upon our experiences.  This is not the first time we had differing opinions and it won't be the last. I highly respect @Ian Mitchell as I do everyone that posts on these forums.  They help add to my experience and have impacted some of my opinions over time. That is the wonderful thing about agile software development and the Scrum Framework.  There is not a single correct answer.


11:08 pm December 3, 2021

In various parts of the Scrum Guide (2020) we can read that Sprint Backlog artifact is created by and for developers. It is created during sprint planning and is clarified as more is learned. It consist of Sprint Goal, selected PBI, and plan for delivering them. And what is worth to mention, PBI that not met DoD can not be released and return to Product Backlog for further consideration.

IMHO that guide us into scenario where once selected PBIs can not be easily removed from Sprint Backlog by PO. Which leaves him with either collaborating about that with developers, or canceling the sprint. Strategy suggested by Ian in my opinion does not align with the Scrum Guide. We can conclude that by this remark about not Done PBI. In order to return something, it must be absent in the first place. So the moment when PBI is selected for sprint, PO lose full control over it as it is no longer part of the Product Backlog for the duration of the Sprint.

However, that does not mean that PO have no voice, he is still part of Scrum Team and the entire team is accountable for the sprint and is empowered to self-manage their work.

In other words the PO must collaborate and not act as a dictator, as the power to manage Sprint Backlog is within the Developers. PO’s dictatorial power is here limited to special card “cancel the sprint if the sprint goal is no longer valid” 😉


12:20 am December 4, 2021

Daniel and Ian, it seems you guys disagree?

Possibly, but this is no evidence. One of us has described what a Product Owner can do, the other what a Product Owner should do.


08:47 am December 6, 2021

In the past, I have successfully been able to explain to Product Owners why it would be a bad idea for them to add things to the Sprint Backlog, rather than to take it to the Developers, and have them make the decision:

Pulling extra work might mean that it is not possible for the people doing that work, to also do something else. It may even put achievement of the Sprint Goal at risk.

By having the Developers choose what to say “yes” to, they can ask what it is OK to say “no” or “not now” to.

Then that work can already be removed from the Sprint Backlog, rather than avoiding that decision and causing disappointment at the end of the sprint.

It enables a more informed, collaborative, and explicit decision to be made.

If necessary, the ultimate explicit decision that could be made would be for the Product Owner to cancel the sprint. This would be a clear choice to abandon progress towards the current Sprint Goal, and replan.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.