Regarding Modification of Sprint Backlog Items after Sprint Planning?

Hi Nitesh,

in my opinion and regarding the practice at our teams it depends on what means to "change the sprint backlog item".

As DT I would not agree to change scope of the sprint backlog item if this makes the goal for the sprint no longer fulfillable by the DT. Then Key-Users (Customers) would start to inject features this way not covered by the PO.

But some times during sprint when development starts we found problems or special cases not covered in the sprint planning and probably nobody (Key-User, PO, DT) was aware of that case. Then we change the sprint backlog item to clarify what is in the sprint and what not, along with a new user story describing the value of what is not yet in the sprint and linking the items by an epic.

> I would not agree to change scope of the
> sprint backlog item if this makes the goal for
> the sprint no longer fulfillable by the DT

That's correct, and therein lies the rationale for modifying a Sprint Backlog in the first place. Specifically the backlog can and should be adapted at any point during the Sprint if this makes the Sprint Goal *more* achievable. Such replanning can be a valid output of the Daily Scrum.

Sprint replanning may affect any (or all) planned tasks for the Sprint, or indeed any (or all) of the selected Product Backlog Items. However, since undone work technically remains on the Product Backlog, any changes to any planned work that is not yet Done must first be negotiated with the Product Owner. In other words if it changes a PBI then the PO must agree.

Adaptations to those parts of the Sprint Backlog which do not impact PBI's, and which do not change the value expected by the PO, are the responsibility of the Development Team. Usually these are represented as the team's tasks and they can replan them as they see fit.