Marking Not Done vs Removed
Hello
Our team committed a PBI and during the initial days of sprint we found out that because of the external dependency we can not complete the committed PBI. So what should be our action plan now -
1. Shall we mark the PBI as Not Done or just remove it from sprint backlog?
2. Team is ready to take next priority work of the same story point, is it allowed during the sprint?
Cheers
Sanjay
Hi Sanjay,
Allow me to share some of my thoughts....
1. I would ask whether there is any value in making this item visible for all? It may be a discussion point at the Retrospective or who knows, the dependency May be fulfilled within the existing Sprint cycle? Ultimately, check with what the Scrum Team thinks?
2. Yes -- if the Dev Team has the ability to take on more, given the circumstances, they should pull the next order of item from the product backlog that is ready. This will also be discussed at he Daily Scrum but I would also bring awareness to the PO.
The PO should be made aware of these as he/she also has to see the potential impact ahead.
One additional thing --
The SM may want to check with the team whether it makes sense to have an "On Hold" status.
There may or may not be value in this for the team.
> ...we can not complete the committed PBI. So what should be our action plan now...
Figure out what you need to do so you can still meet the Sprint Goal. Was this PBI essential to the goal, or can you find a workaround that will allow you to deliver the increment?
If there is a workaround, inform the Product Owner of the issue and the solution you propose which should still allow the Sprint Goal to be met.
On the other hand, if the PBI is essential to the Sprint Goal, the Product Owner should be notified and told that the increment is at risk because of the external dependency. The PO and Scrum Master can then work together to overcome that blockage. Failing that, the PO can work with the Development Team to revise the Sprint Backlog in order to meet an alternative goal of suitable value.
In either case, it will be essential to address this problem in the next Retrospective. This is because the Development Team clearly do not own their process and are unable to take each item on their Sprint Backlog through to completion. The required technologies and skills should either be brought in-house (i.e. into the team) or PBI's with such dependencies should not be accepted by the team in the first place.