Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Product Backlog VS Sprint Backlog - Who owns What?

Last post 08:11 pm March 29, 2022 by Mario De Caerlé
1 reply
02:55 pm March 25, 2022

Along my career I have seem some confusion about Product Backlog and Sprint Backlog and who owns what.

If you follow the Scrum Guide that should be very simple.

Product Backlog: is owned by the Product Owner, it his/her responsibility to keep it organised and ordered by value.

Sprint Backlog: is owned by the Developers, it is their responsibility to keep it organised and representing the most recent state of the work.

So what is the confusion?

Some Product Owners think that they control the Sprint Backlog and start to add items to it causing confusion and disrupting what was agreed on the Sprint Planning. The Product Owner should never add items to the Sprint Backlog it belongs to the Developers.

There is no workaround on it, if an item have to be included in the Sprint Backlog the Developers must be consulted and they will decide if it will be added to the Sprint Backlog and it should be added only if it will not affect the Sprint Goal.…


What are your thoughts about that?

08:11 pm March 29, 2022

For a team that exists a while, there will be issues that need to be inserted in a Sprint. There will be a bug or a feature that the stakeholders feel needs to be addressed right now. And that is possible.

First: try not to do this. If it can wait, the PO can add it to the Product Backlog.

If it really needs to be done now, the PO calls the Developers and discusses the issue. If the Developers agree the item needs to be added to the Sprint Backlog, they add the issue to their Sprint Backlog (and start working on it). Probably another item needs to be removed from the Sprint Backlog. There is a bigger effect.

Now, for completion, I have to add that Dan Vacanti has an interesting talk on "expedites" ("How An Expedite Request Sunk the Titanic"), and how when you do this often, it will ruin your workflow, planning, delivered value and thus the health of the whole team.