Who can change the Sprint Backlog?
p15: "Only the Development Team can change its Sprint Backlog during the Sprint"
p10: "If the work turns out to be different than the Development Team expected, they COLLABORATE WITH THE PRODUCT OWNER to negotiate the scope of Sprint Backlog within the Sprint".
So P10 implies that the Development Team CANNOT change the Sprint Backlog (or at least the selected Product Backlog Items within it) without collaborating with the Product Owner. However the question in Mikhail Lapshin's PSM examples takes the p15 interpretation and marks the p10 interpretation as wrong.
I can see that the Product Owner alone cannot change the Sprint Backlog.
Hoping that this isn't one of the real questions in PSM1.
Both statements are from the Scrum guide. Try and see how they may both be correct.
My take is that the Sprint Backlog is the plan to achieve the Sprint Goal and the plan can change based on uncovering additional information by the Development Team as long as it does not endanger the Sprint Goal. If the Sprint Goal cannot be achieve by the Development Team, then the Development Team needs to collaborate with the PO to adjust the Sprint Goal. Correct?
PO to adjust the Sprint Goal
Sorry meant Sprint Backlog.
Development team cannot drop or add PB items without the PO.
Development team can drop or add tasks to deliver PB items according to the definition of done.
I think you may be confusing collaboration with ownership.
The Sprint Backlog is a subset of items pulled from the Product Backlog. These two artifacts are fundamentally linked by their definitions. If the Development Team is the sole owner of the Sprint Backlog, and the Product Owner is the sole owner of the Product Backlog, then some level of collaboration still has to happen.
However, the purpose of that collaboration is not to get approval or direct input for the Sprint Backlog revisions. The Product Owner's role at this point is to prioritize the Product Backlog so developers know which tasks are the highest value, as well as to determine if the Sprint should be canceled as a result of this new information.
If you note the Scrum Guide's liberal use of the word "may" on the Page 10 description, you'll catch that this collaboration isn't obligatory, just implied/recommended. If the Product Owner is unreachable, the current Product Backlog, Team Velocity and Sprint Goal can still be used to update the Sprint Backlog without any further input.
I think mu problem was that questions about using Scrum in the real world are not always amenable to a simple true/false answer. Sometimes you have to look at the pragmatic solution and make sure it fits the Scrum framework. It isn't always possible to do this in the context of a multiple choice exam, but you know what you would do if you actually had to deal with the situation.
Development team cannot drop or add PB items without the PO.
If you are referring to the Product Backlog, and not the Sprint Backlog, then I would agree with your statement. The PO owns the Product Backlog.
If your statement is in reference to the Sprint Backlog, then I would question it.
Per the Scrum Guide: "The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint... Only the Development Team can change its Sprint Backlog during a Sprint."
Hi Timothy, thanks for your feedback.
I've understood that anybody can add to the Product Backlog, the Product Owner prioritizes the items. During the Sprint Planning, the Development Team decides how many of the prioritized PB items they pull into the Sprint Backlog.
If during the Sprint they find they cannot finish all items or they will finish all items before the end of the Sprint, they confer with the product owner on which items to drop/add.
But, as I am not a Scrum master in practice, I can easily get it wrong. What is you're take on this?
Who can change the Sprint Backlog? - Is really a need for this for a given time-box sprint? In case such need arise due to business priorities, then PO is authorize to make these changes (re-arranging scope and acceptance criteria) in consultation with SM/Team. Re-arranging scope of running sprint, reflects need of business urgency, thus PO should discuss & assess impact on sprint before any changes.
In regards to allowing anyone to add items to the product backlog, I would caution against that approach. Giving such a wide permission for people to fill up the product backlog can result in a maintenance headache for the Product Owner. It is critical that the Product Owner be viewed as the "owner" of the PB, and any potential stories should first be presented to the PO to determine if it is valid/important. Allowing the PB to be filled up with items submitted from numerous sources simply creates a lot of waste around maintaining items that have a low priority.
Sprint Planning does not consist simply of the Dev Team selecting the highest priority PB items into the sprint. The PO will present a list of PB items as an "offer" to the team, along with their vision for the next sprint. The Dev Team will then work through that list and determine what they feel they can comfortably forecast to complete over the next sprint. This may involve an ongoing negotiation with the PO over items offered, and possibly adding/removing items as needed to reach agreement on what the next sprint will look like. The Dev Team should not select any PB items for their Sprint Backlog that were not part of the original PO "offer", unless there is consent by the PO for those items.
So yes, you are correct in that the PO prioritizes the PB, and the Dev Team determines what actually ends up in the Sprint Backlog, but it is not as straightforward as that.
If the Dev Team determines during the sprint that they may have additional capacity, one option is to negotiate with the PO on bringing in additional PB items into the sprint, with the clear caveat that the Dev Team can complete the new items by sprint end. Other options to manage extra capacity may involve additional refinement activity, learning/cross-training, knowledge transfer, etc.
If the Dev Team believes they may not get all of the forecasted work done in the sprint, they can negotiate with the PO on which stories they may be able to de-scope while still meeting the Sprint Goal. This is why it is critical to work on stories in prioritization order, and to limit work in progress, so that if there is a need to de-scope, the lowest priority non-sprint goal item(s) that (hopefully) have not been started yet can be removed.
Hope this helps, and I welcome any feedback if my own understanding is inaccurate.
Excellent. Thank you for your valuable insights.
Everyone, I am planning to take the assessment this week. Between several practice assessment and Scrum Guide, I am still very confused on this topic: Just to summarize: Please confirm if followings are true.
My understanding is:
PO owns the Product backlog and is responsible for managing it to meet product goal. He/She is the only one who can change it with the suggestions from others..
Dev Team owns the Sprint backlog and changes it during the Sprint to deliver the increment. During the Sprint review, the PO updates product backlog based on increment review and updated Sprint backlog.
Thanks. Appreciate your help.
This question is again here...."Who is allowed to make changes in the Product Backlog?"
My understanding is that it is only the PO. But there is an answer shown in one of the sites that it could be "the development team with the permission of the product owner"
Yes, this could also be true, but for the assessment what should be the best answer, if both options are available? Only select PO as the answer or select both?
Years later and this is still not a clearly known item...or rather the wording in the Scrum guide lends itself to different interpretations. Googling the subject yields a distribution of answers that is fairly even. It would be nice to have a definitive clarification that sounds less ambiguous than the guide itself.
@Neil, I would say there are 2 pieces in the Scrum Guide that make it quite clear that only the Developers can change the Sprint Backlog:
"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."
"For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value."
In my experience, when people find ambiguity in the Scrum Guide, it is very often because it says something they do not wish to hear.
Our attitudes and perceptions are often shaped by the companies we work for, and we can sometimes end up reflecting them. As a result, Googling a subject will yield a distribution of views about Scrum.
The Guide is quite clear about the Developers' authority over the work they do to meet their agreed commitments. The starting position in many organizations, however, is that surely the Scrum Guide must mean something else, because this interpretation:
- is idealized and unrealistic,
- defies organizational policy and common sense,
- reflects naïvity and/or immaturity on the part of the Scrum professional claiming it,
- fails to acknowledge that we are special in this company, and
- therefore cannot possibly be the case.
Developers can change the Sprint Backlog. Sprint Backlog is planed by Developers and define the work necessary to create an Increment that meets the Definition of Done. Developers change the Sprint Backlog after consulting with PO.
Don't forget that PO is not the boss of Scrum team. He is a member of the Scrum team. All decisions of the Scrum team(I mean ALL) are made collectively by negotiation within team members(which includes SM and PO) .So generally speaking .
So when we are saying that "Only the Development Team can change its Sprint Backlog during the Sprint" it basically means that no outsider-stakeholder, owner of organisation, someone else can dictate changing the Sprint backlog.
While team(developers+scrum master+product owner who are all EQUAL members without any hierarchy) can.
Another provision which you mentioned, ""If the work turns out to be different than the Development Team expected, they COLLABORATE WITH THE PRODUCT OWNER to negotiate the scope of Sprint Backlog within the Sprint" suggests the best way to change the sprint backlog, considering that both developers and PO are member of same team and should make a decision on most thing unanimously and collectively.
But in the hypothetical situation when PO is indifferent or absent developers can actually change Sprint backlog themselves.
Please remember however that PO is owner of Product backlog and eventually has full control.
To end this Scrum is a vivid living methodology, not the dogm, and any guidebook is merely a suggestion, and not the rule.