When the sprint backlog can change?
Hi,
When the sprint backlog can change?
Both remove an item because it no longer makes sense for the scope or add an item just because the sprint backlog is over, but the sprint timebox not yet.
What are the rules and what are the exceptions?
thanks,
Maicol
Hi Maicol
In both of the situations you describe, the sprint backlog should be replanned immediately. There is usually no value in progressing a redundant PBI or in having a team wait until the end of a sprint before accepting more work.
Note: only the development team can change the sprint backlog, because they own it. Nothing can be put in or taken out without their authorisation.
+++++1 to Ian's response, though I would also add that the PO should be involved in the discussion about what is dropped or added to a Sprint.
In terms of adding or removing scope, you might find this chart helpful:
http://www.scrumcrazy.com/scope
The whole team including PO should be involved while adding/removing anything from the sprint backlog. While adding anything new it should be PO's decision to take the top priority item from product backlog and move it into the sprint backlog.
The team should be transparent in telling about any change in the sprint backlog during the sprint review meeting.
Sanjay,
I want to make a distinction in your advice. The Sprint Backlog is "PBI's + a plan to deliver the PBI's". The PO doesn't ever really have to be involved if the "plan" changes, but they do have to be involved if the PBI's change materially (or the number of them forecasted for the sprint changes materially).
So, while the PO must be involved in the decision to add/change/drop PBI's, they need not be involved in any changes to the "plan". It is also ok if the Dev Team wants to involve the PO in changing the "plan".
Also, the Scrum Master doesn't need to be involved in any of the above, except as needed to make sure that Scrum is followed.
Does that make sense?
While adding anything new it should be PO's decision to take the top priority item from product backlog and move it into the sprint backlog.
Also, this is not always the case. The PO may decide to bring a PBI into the sprint that is *not* the top priority item from the PB. They may have other reasons for bringing something different into the sprint, which is why they should always be involved when changing the "scope"(PBI's) of the Sprint Backlog.
It's also worth nothing that priority is just one factor when ordering the Product Backlog. Other factors are necessity, technical dependency, business value, etc. See the Scrum Guide for more info on that.
Yep
My idea was on adding/removing a PBI in the sprint backlog. I agree that PO and SM should not be involved in sprint execution plan.
Hi All,
I would actually agree with Charles and Ian but I was going through the book "Agile Project Management with Scrum"
by Ken Schwaber and he acttually talks about a frozen product backlog in the sprint.
He litterally says: "The Team commits to Product Backlog during the Sprint planning meeting. No one is allowed to change this Product Backlog during the Sprint. The Product Backlog is frozen until the end of the Sprint."
So apparently no Items can be added.
The weird thing is that he also states:"the ScrumMaster can abnormally terminate the Sprint and initiate a new Sprint planning meeting to initiate the next Sprint. The
ScrumMaster can make this change of his or her own accord or as requested by the Team or the Product Owner." This contradicts the scrum guide.
The only explanation I can give is that his book is frm 2004 and maybe he modified scrum framework.
Can anybody explains this because it generates huge confusion.
Thanks
> The only explanation I can give is that his book
> is frm 2004 and maybe he modified scrum framework.
Absolutely right.
I have the same Question... Please Help......
Posted By Filippo Cecchini on 02 Mar 2016 10:48 AM
He litterally says: "The Team commits to Product Backlog during the Sprint planning meeting. No one is allowed to change this Product Backlog during the Sprint. The Product Backlog is frozen until the end of the Sprint."
So apparently no Items can be added.
Filippo,
Ask yourself if a "frozen" sprint backlog supports agility.
Be wary anytime the emphasis is placed on process. Rigidity does not support agility!
Agile Principle #2 - "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
Timothy I fully agree with this approach. Nevertheless in some materials preparing to PSM certificate I have found question: "who can change the sprint backlog items?" I thought about the Development team, but the correct answer was: "Noone, Note that development team is always changing the tasks."
Fore me it was obvious that if something happens there is a need to change sprint backlog 'even late in development' - but after this question - I am greatly confused. Do you have any idea how to logically explain those 2 different approches? I would be very greatful if you - or anyone who understands it - could help.
: "who can change the sprint backlog items?" I thought about the Development team, but the correct answer was: "Noone, Note that development team is always changing the tasks."
I too am confused. What’s the source of the question?
According to Scrum, the Sprint Backlog can only be modified if it doesn’t mutate the Sprint Goal. The Development Team is in charge with managing the Sprint Backlog and can edit it if in accordance to this principle.
If they feel that their edits will significantly change the Sprint Goal then they collaborate with the Product Owner about this issue. ‘
Only under extreme circumstances may the Product owner cancel a Sprint (changed goals). However, due to the short duration of Sprints this minimizes the likelihood of cancellation arising.
Posted By Anna Kalita on 17 Aug 2016 07:00 PM
Timothy I fully agree with this approach. Nevertheless in some materials preparing to PSM certificate I have found question: "who can change the sprint backlog items?" I thought about the Development team, but the correct answer was: "Noone, Note that development team is always changing the tasks."
Fore me it was obvious that if something happens there is a need to change sprint backlog 'even late in development' - but after this question - I am greatly confused. Do you have any idea how to logically explain those 2 different approches? I would be very greatful if you - or anyone who understands it - could help.
Anna,
The Scrum Guide explicitly states the following:
"Only the Development Team can change its Sprint Backlog during a Sprint. "
You need to be careful with any exam sources provided by 3rd parties, as they may promote an imperfect understanding of Scrum, and provide confusion instead of clarity around Scrum.
The Sprint Backlog can change during a sprint as the Development Team works towards the Sprint Goal. The Sprint Backlog is simply a plan, and that plan can change. Think of it along the same lines of Progressive Elaboration in traditional project management, where you don't know what you don't know until you actually begin the work, and you learn as you go along.
Changing the Sprint Backlog does not have to be a huge event, although if "something happens" that puts the Sprint Goal into question, then certainly the Sprint Backlog, and even the Sprint, can not only change but also be at risk.
@Doug and Timothy, many thanks for your answers and explaining this topic.. I was using Management Plaza training cards. Yes, definitey next time I will relay only on scrum guide - no exceptions. Thank you!
I took the open assessment and encountered this question "During a Sprint, a Development Team determines that it will not be able to finish the complete forecast. Who should be present to review and adjust the Sprint work selected?"
Answer is The Product Owner and the Development Team.
I got it wrong as I chose Development Team. I guess it is how the question being phrased that catch me off-guard.
I think this echoes Charles' feedback that even though SBI owned only by Dev Team but it is the joint effort of changing the work/scope of SB between Product Owner and Dev Team because it will affect the Sprint Goal.
Reading Scrum guide give me second thought about what I mention above.
I always thought that "Work" is the decomposition of the SBI in the form of tasks as part of the plan to deliver Done Increment in the sprint. That should align with the Scrum Guide statement - "The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team"
Based on my understanding, work belongs and owned by Development Team.
But apparently the answer from Open assessment suggest that Product Owner involvement. Or just how the question being phrased that make me confuse.
Can someone please share your enlightenment?
The Sprint Backlog is wholly owned by the Development Team and only they can change it.
Suppose the team amended the Sprint Backlog by reducing the forecast of functionality, while ensuring that the Sprint Goal can still be met. Don't you think they should involve the Product Owner in this revision, so he or she can appraise stakeholders of the reduced functionality, and update the Product Backlog to indicate that work originally planned is no longer in progress?
Thanks Ian. That's thought-provoking.
The sprint backlog is impacted by scope volatility, swelling, issues, defects and urgent stack holder requests. To deliver a higher value, the PO can convince team to bring in change to Sprint Backlog. At the same time, if team feels any planned Backlog Items does not create a higher value to customer, team can inform PO. Team and PO together shall update the sprint goal.
Can the product backlog change during a sprint? Thanks!
From the Scrum Guide:
The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful.
Based on that, what is the answer to your question Sue?
As a new member, I would welcome how the community feels about complying with auditors who will be looking for strong change controls when the backlog is changed. As an IT auditor myself I am inclined to look for strong controls over the MVP as it relates to the business and benefits case rather than the day to day activities of the sprint. However, if the system is a financial system then even adding something 'extra' (above and beyong the MVP) would have to be carefully controlled and sanctioned.
One question about changes into Sprint Backlog. Who is allowed to change the Sprint Backlog during the Sprint? The Development Team or.... The Development Team and the Product Owner.
The Scrum Guide says: "The Sprint Backlog is a plan by and for the Developers", and: "Developers are always accountable for <...> Adapting their plan each day toward the Sprint Goal"
The Developers own and maintain the Sprint Backlog. They are the only ones that can make changes to it. I recommend to them that they inform the Product Owner of changes so that everyone is informed of why a change occurred. If the Product Owner has a strong reason for a change to the Sprint Backlog, they can approach the Developers to discuss the need. But it is up to the Developers to decide if that change is warranted.