Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
"The Sprint Backlog is the set of Product Backlog items selected for Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal".
The Product Backlog is Sprint's way of limiting work in progress. When Sprint Planning is over, the Sprint Backlog is locked down. At that point, adding anything to the Sprint Backlog should be vigorously resisted. The Scrum Master should protect the backlog from external influence. But, is the Sprint Backlog fixed? If at that point, there is work required to produce an acceptable increment, can new work be added to the backlog?
Can you add work to the sprint backlog, during the course of the sprint? Saving Changes...
I wouldn't put it like that. The Scrum Guide says:
"The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal."
Only the PO can change the goal but the development team owns the sprint backlog and modifies it as required. Saving Changes...
In an ideal environment, work will not be added once the backlog is locked down. But we don't live in a perfect world. So work is added even after the sprint backlog is defined, locked down and in progress. We can push to deprioritize the existing items in the sprint when a more priority item is added. However, given that the sprint itself is only 2 weeks, the team has already started working on the existing sprint items and it might be challenging to remove the items from the sprint. In anycase, it is the job of the PM to disallow or push back on changes in the sprint after the sprint is defined and locked down.
...
1 reply by Marcus Udokang
Jul 23, 2020 3:40 PM
Marcus Udokang
...
Would it be the PM or the development team that would push back or allow changes to be made to the product backlog.
Here's a couple of reasons that work could be added to the backlog:
1. A critical defect is identified "in the wild" which needs to be resolved. This doesn't imply the team has to take it on in addition to what they had forecast but they might size and swap work items to accommodate it.
2. The team has capacity left over after completing all sprint backlog items
Remember that sprint planning is a forecasting exercise and NOT a commitment-making one. That was a change made in the Scrum Guide from its earliest versions. Even though the time horizon is short (1-4 weeks) there are still uncertainties which could impact what the team will complete.
Kiron Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
Jul 23, 2020 5:02 AM
Replying to Maria Lekha Johnson
...
In an ideal environment, work will not be added once the backlog is locked down. But we don't live in a perfect world. So work is added even after the sprint backlog is defined, locked down and in progress. We can push to deprioritize the existing items in the sprint when a more priority item is added. However, given that the sprint itself is only 2 weeks, the team has already started working on the existing sprint items and it might be challenging to remove the items from the sprint. In anycase, it is the job of the PM to disallow or push back on changes in the sprint after the sprint is defined and locked down.
Would it be the PM or the development team that would push back or allow changes to be made to the product backlog.
...
1 reply by Maria Lekha Johnson
Jul 23, 2020 4:06 PM
Maria Lekha Johnson
...
hehehe, the dev team pushes the PM and the PM pushes back on the client. But many times the PM itself will know that the team cannot take new changes even before checking with the dev team. So the PM generally goes back to the dev team to know if they can accommodate new changes only if he/she has doubts.
In a small sprint of 2 weeks, the dev team does not have much time to check if these new changes can be accommodated and if any other user story has to be deprioritized. So the PM needs to serve as the first level of filter. The dev team's time is a precious commodity in small sprints.
Would it be the PM or the development team that would push back or allow changes to be made to the product backlog.
hehehe, the dev team pushes the PM and the PM pushes back on the client. But many times the PM itself will know that the team cannot take new changes even before checking with the dev team. So the PM generally goes back to the dev team to know if they can accommodate new changes only if he/she has doubts.
In a small sprint of 2 weeks, the dev team does not have much time to check if these new changes can be accommodated and if any other user story has to be deprioritized. So the PM needs to serve as the first level of filter. The dev team's time is a precious commodity in small sprints.
...
1 reply by David Portas
Jul 24, 2020 1:11 AM
David Portas
...
Hi Maria,
The official Scrum answer is that there is no PM in Scrum and that it's the PO, not the PM, who has the first and last word about changes to the scope of a sprint. Where a PM is working in a Scrum context, he or she ought to be willing to take a back seat and let the PO make such decisions - otherwise the PM risks undermining the dynamic of the Scrum team and its accountability to stakeholders.
Of course it's true that some PMs also work as POs and may even transition into a full time PO role, but it's still sensible to maintain the distinction between the two.
Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
@David, @Maria, @Kiron, appreciate the valuable responses. Saving Changes...
Khai Ng.IT PMO | IT Project Manager| TTGROUPHanoi, Viet Nam
Product backlog items selected for the Sprint are locked, any changes to them need to be approved by PO, but the works need to be executed to deliver product are added or removed as needed by the Development Team. Saving Changes...
hehehe, the dev team pushes the PM and the PM pushes back on the client. But many times the PM itself will know that the team cannot take new changes even before checking with the dev team. So the PM generally goes back to the dev team to know if they can accommodate new changes only if he/she has doubts.
In a small sprint of 2 weeks, the dev team does not have much time to check if these new changes can be accommodated and if any other user story has to be deprioritized. So the PM needs to serve as the first level of filter. The dev team's time is a precious commodity in small sprints.
Hi Maria,
The official Scrum answer is that there is no PM in Scrum and that it's the PO, not the PM, who has the first and last word about changes to the scope of a sprint. Where a PM is working in a Scrum context, he or she ought to be willing to take a back seat and let the PO make such decisions - otherwise the PM risks undermining the dynamic of the Scrum team and its accountability to stakeholders.
Of course it's true that some PMs also work as POs and may even transition into a full time PO role, but it's still sensible to maintain the distinction between the two. Saving Changes...
Marcus UdokangProject Manager| Aivaz ConsultingCalgary, Alberta, Canada
