Adding / Removing Sprint Backlog Items
Hi,
I'm confused about Sprint Backlog Items. Could we change the items of the Sprint Backlog after the Sprint is started and the plans are set ?
In scrum guide, they say that : "The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint."
But it's not clear, do we speak about adding or removing items ?
We talk about replanning the forecast of work needed to achieve the Sprint Goal. That forecast is the Sprint Backlog, and replanning may involve adding and/or removing items. The Daily Scrum is an opportunity to inspect and adapt the team's forecast.
Hi, allow me to update and share another question to this topic.
Developers can "add" PBIs, I agree with that specifically if the dev. team is decomposing some activities into smaller pieces once the developer understands better the requirements, considering of course he will not change the GOAL of the sprint, which should remain as defined during the Spring Planning with the PO.
But, some test questions I'm seeing asks about who is the responsible to manage the Product Backlog. According to the Scrum Guide and the answers I found, the "sole responsible for managing the PB is the Product Owner". However, considering what I wrote just before, does it make sense to say that the PO is the "sole responsible"? I believe he is the responsible for the PB, but the dev. team can update it too ... am I wrong?
Thanks!!
> ...does it make sense to say that the PO is the "sole responsible"?
> I believe he is the responsible for the PB, but the dev. team can update it too .
A Scrum Team is expected to collaborate and each role has clear responsibilities in this regard. For example, the Product Owner wholly owns and is responsible for the Product Backlog, but the Development Team must help to refine it.
Hi Ian,
Thanks for your comment! Actually, you just confirmed what I think.
But, to be honest, the question remains. I know how this works in practice, but the Scrum Guide and the mock questions I'm practicing are too straight stating the responsibility under PO. This seems that he is the only one responsible to work on it, which is not true. Anyway, the answers are bit dubious, that's what I'm suffering, to know the correct answer and pass the exam! :)
Thank you!
Hello
Original query was regarding Sprint Backlog items- which is owned by Development team.
>> Could we change the items of the Sprint Backlog after the Sprint is started and the plans are set ?
- As team learns more about the requirements - more tasks might get identified and can be added to "Sprint backlog" - in a away adding/refining backlog during sprint.
- More PBI could also be added and for that matter could be removed as well - however this needs to be done in consultation with PO.
Thanks
Pankaj
I do agree with Hajer,
I think the Guide has several fragmented info about this issue that might be understood in serveral ways.
There is a direct reference about renegotiate the selected Product Backlog items:
If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner
but this refence is done in the Sprint Planning section. So it's obvious it can be done here.
But, when the Sprint Planning is finished, we can find other references.
During the Sprint:
No changes are made that would endanger the Sprint Goal;
....
Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
The key word here for me is Scope. Can be Scope an item, or only Tasks. How the item will be done
to work around a forecast problem and wouldn't endanger the Sprint Goal.
In the first case, a Item removed could endanger the Sprint Goal and to be necessary to craft other Sprint Goal.
And one special case, if a Sprint Backlog Item doesn't endanger the Sprint Goal, and the forecast work
exceeded the capacity team because of new work emerged, might the Item be removed?
Thank you in advance.
Hi,
I've found a reference about this subjet in the next book Scrum Narrative and PSM Exam Guide
Does the Development Team have any flexibility to change the scope or duration of
a Sprint?
The Sprint duration is constant and gets over on a preset end date. The end date of the
Sprint is not advanced or extended no matter what.
However, the Sprint Goal provides some flexibility to the Development Team. The
scope may be clarified and re-negotiated between the Product Owner and Development
Team as more is learned. Accordingly, Product Backlog items for the current Sprint can
be modified, as long as these changes do not endanger the Sprint Goal. If the Sprint
Goal is impacted due to the changes, the Sprint shall be cancelled.
Here is talking about modify, not remove. And this re-negotiation is done after the Sprint Planning, because it is talking about cancel the Sprint if the Spring goal does endanger. If we were in the Sprint Planning it wouldn't be necessary to cancel it.
As previously recommended, it is best to use the Scrum Guide as the official Scrum reference, and lightly consider all other source material, as their understanding and practice may not be completely accurate.
Regarding the below excerpt from the Scrum Narrative book:
The scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned. Accordingly, Product Backlog items for the current Sprint can be modified, as long as these changes do not endanger the Sprint Goal. If the Sprint Goal is impacted due to the changes, the Sprint shall be cancelled.
Only the Product Owner has the authority to cancel a sprint, and this is done when the Sprint Goal no longer makes sense. This is a very rare outlier to the rule. In almost all cases, the Sprint Goal discussed and decided upon between the PO and the Development Team remains relevant throughout the sprint.
I have personally performed as a Scrum Master serving many teams and PO's, and while I have seen many instances of scope change, I have never seen a sprint canceled because the goal decided on was suddenly not relevant to the business a week or two later.