Changes to the Product Backlog
Hi all :),
I was having a discussion regarding Product Backlog management, who can do what and someone said that "anybody can put something in the backlog, the PO orders the backlog".
I disagree with this sentence as, to me, only the PO can create a Product Backlog Item (or someone he delegated this, but even then he remains accountable). My opinion is also based on my interpretation of this sentence in the Scrum Guide : "Those wanting to change the Product Backlog can do so by trying to convince the Product Owner." which means, according to me, that if someone that hasn't been delegated by the PO to make some changes to the Product Backlog wants to add something, the only way is to convince the PO that this addition needs to be done, and then the PO might add the item.
What do you think?
This is my interpretation so take it for what it's worth.
There is nothing that says the Product Owner is the only one that can create items in the backlog. The statement you reference only says that the Product Owner needs to be convinced to make a change. Why couldn't a Developer convince the Product Owner that an item needs to be created to address some technical debt and then create the item so that it accurately represents the need?
The Product Owner is responsible and accountable for ensuring the Product Backlog contains all of the work needed to improve the product. But the work to refine those items is shared by the Scrum Team. It is not uncommon for new items to be created while that refinement is being undertaken.
I agree with Daniel that I cannot find any references in the Scrum Guide that support the statement that only the Product Owner can create Product Backlog Items. Although the Scrum Guide does state that the Product Owner is accountable for "creating and clearly communicating Product Backlog Items", it goes on to say that "the Product Owner may do the above work or may delegate the responsibility to others". All the teams that I've worked with have delegated the creation of a Product Backlog Item to the whole team, with the Product Owner remaining accountable for making sure that it clearly represents valuable work to stakeholders and that it is properly ordered among all other Product Backlog Items.
I've always interpreted the statement about people wanting the change the Product Backlog referring to cases where people disagree with the Product Owner on an action. Since the Product Owner is accountable for all aspects of effective Product Backlog management and the decisions of the Product Owner are respected by the organization, no one can overrule or override a decision that the Product Owner has made with respect to the Product Backlog. Those decisions could include reordering an item to be lower in the Product Backlog or even removing an item added by someone else.
Just because this is how the teams that I've worked with have worked doesn't mean it's how all teams work. I don't see how your interpretation is inconsistent with the Scrum Guide. That is, I don't see anything that would inherently prohibit a team from establishing a way of working where the Product Owner is the only one who can insert a Product Backlog Item onto the Product Backlog. However, I would be curious about how effective a team is if the team is relying on the Product Owner to effectively be an administrator of Product Backlog Items on top of their other product management responsibilities.
if someone that hasn't been delegated by the PO to make some changes to the Product Backlog wants to add something, the only way is to convince the PO that this addition needs to be done, and then the PO might add the item
Correct, although it might be better to say that the PO would then allow the addition of the item. As you noted, the responsibility for doing so may be delegated. The same goes for removing items.
If something isn't there, it may well be because the PO doesn't want it there. The Scrum Guide says: "For Product Owners to succeed, the entire organization must respect their decisions". Those who claim that "anybody can put something in the backlog" may not fully understand the Scrum Values, of which respect is one.
Thanks all for your answers!
@Daniel Wilhite & @Thomas Owens I haven't been able to express my thoughts clearly enough, and @Ian Mitchell found the perfect phrasing :)
What I meant was that the thing bothering me with the "anybody can put something in the backlog" sentence, is that the addition can be done without the PO allowing it. And what I wanted to express is that, in my understanding, any addition to the Product Backlog needs to be done with the PO's approval. Now, after the PO approved the addition, how the item is added to the Product Backlog is up to the team obviously.
Hope it's clearer this way!
The only thing I would add to this is that “anyone” doesn’t mean just anyone.
As I understand it, the Product Owner can delegate the responsibility so that anyone on the Scrum Team may add PBIs to the backlog. Product Backlog isn’t a repository for any and all ideas, it emerges to define what is needed to fulfill the Product Goal.
You may have intended this but wanted to clarify just in case.
What I meant was that the thing bothering me with the "anybody can put something in the backlog" sentence, is that the addition can be done without the PO allowing it. And what I wanted to express is that, in my understanding, any addition to the Product Backlog needs to be done with the PO's approval. Now, after the PO approved the addition, how the item is added to the Product Backlog is up to the team obviously.
Scrum doesn't require that teams work in the way you are describing. Although it is a valid way of working, meaning that it doesn't contradict the Scrum Guide, I don't think it's an effective way of working.
If all of the stakeholders need to ask the Product Owner every time they want to add something to the Product Backlog, the Product Owner will have little time to do other, more valuable things. Since the Product Backlog is a list of "what is needed to improve the product", Developers will frequently come across needed improvements during the course of their daily work. If the Developers can't record these potential improvements in the Product Backlog immediately, you run into the risk of forgetting things that should be discussed or perhaps a second source of work. And a Scrum Team should not have two sources of work - the Product Backlog "is the single source of work undertaken by the Scrum Team".
Exactly what do you see is the problem if the Product Owner allows the Developers, or perhaps other key stakeholders, to create Product Backlog Items directly and even take a first attempt at prioritizing them? Especially if the team is using electronic tooling to manage their Product Backlog, the Product Owner should be able to quickly see items that have been added (or modified) recently and review them, making the appropriate updates. Electronic tooling can also help provider a filter to allow stakeholders to track the state or status, including things that have been reviewed and ordered by the Product Owner or things that are pending refinement by the Scrum Team or things that are ready for an upcoming Sprint.
This comes from the Scrum Guide's section that explains the Product Owner's responsibilities. The same section of the guide that has the statement you are concerned about.
The Product Owner is also accountable for effective Product Backlog management, which includes:
Developing and explicitly communicating the Product Goal;
Creating and clearly communicating Product Backlog items;
Ordering Product Backlog items; and,
Ensuring that the Product Backlog is transparent, visible and understood.
In my opinion if the Product Owner is doing all of these things well, I would not expect that people would be want to add items to the Product Backlog that does not support the Product Goal. That same section opens with this statement.
The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The process you suggest does not contradict with that statement. It is just not a way that any of the teams that I have worked with or beside have ever chosen to operate. I have worked with teams where the Product Owner has chosen to remove from or order to the bottom items that were not in align with the Product Goal. Since the organization respected their decisions there was never any issues that occurred from those actions.
Exactly what do you see is the problem if the Product Owner allows the Developers, or perhaps other key stakeholders, to create Product Backlog Items directly and even take a first attempt at prioritizing them?
If the PO allows the Developers or key stakeholders, then to me we are in the case where the PO delegated the creation of PBIs, which I agree with, as I put in my opening post :
to me, only the PO can create a Product Backlog Item (or someone he delegated this, but even then he remains accountable)
As @Ryan Kent put it, there is the risk that the Product Backlog may become a repository for ideas instead of an ordered list of the work needed to be done in order to create the product and reach the Product Goal; but if the Product Owner knowingly delegated this responsability, he remains accountable so it would be up to him to handle this risk (this is a different case than having someone adding PBIs without the PO delegating the responsability to this person, which to me shouldn't happen).
the Product Owner should be able to quickly see items that have been added (or modified) recently and review them, making the appropriate updates
Personal opinion : Moving away from Scrum theory and based on my experiences, if "anyone", the Developers, or key stakeholders, add items in the Product backlog, you quickly have a Product backlog that is gigantic, tough to maintain and contains everything and anything, from valid points to "nice to have" stuff put in by a key stakeholder. Then the PO has to, often, synchronize with the person who added the item to ensure that he understands what was the idea behind, see if he thinks the idea is valid or not, discuss to see if it is going to be kept in the PB etc etc...having those back and forth chats, on top of other accountabilities is extremely time-consuming.
Once again, thanks for the insights and various point of views, all are very helpful
I am not sure to which discussion you refer to, but it's me who suggested that future updates of Scrum Guide should "open" Product backlog to everyone, and every upcoming piece of information.
This will allow further alignment of Scrum with the constantly automated IT industry, particularly with DevOps, machine learning (AI) and new QA techniques.
Product Owner, however, should have exclusive right to decide which PBI's to keep, and which to delete..