Move PBI from sprint backlog to product backlog mid-sprint

[Opinion]

Yes -- bring the PO into the conversation as soon as possible. Even if the PO isn't avaialble for some reason, the backlog should remain visible and reveal some items are indeed *ordered* at the bottom of the list.

I would leave the item(s) in the Sprint backlog itself. Allow the team to discuss this in the retrospective. I.e. Why couldn't we get to these items, even though, we planned for these? Etc.

Also, one never knows if there's an impediment to other sprint backlog items that may allow the Dev Team to work on something they thought couldn't be done.

I've also worked with teams where things have been kicked out very quickly after Sprint Planning. Eg -- day 2 of a 2-week sprint. This encouraged the Dev Team to finish planning quickly & negotiate scope early on, if possible.

When there is a lot of work emerging or the team is taking on too much, it's an indication of a pattern, rather than an exception. The observant ScrumMaster should try to bridge he gap by making things visible and reflect back to the team. This scenario should eventually become an exception, and not he norm...

[/opinion]

>...don't have time to complete the lowest priority PBI in the
> sprint, should they discuss it with the Product Owner and if
> it's found to not jeopardize the sprint goal then move it
> back to the product backlog immediately? 

That's a plausible scenario. However it's important to draw a clear distinction between priority (in the sense of order) and value.

The Sprint Backlog is wholly owned by the Development Team, and it is up to them to decide how and when work will be actioned to meet the Sprint Goal. Unless they have made arrangements with the PO to deliver elements of the Increment during the Sprint, the priority given to each PBI actioned during the Sprint will therefore be up to them.

This makes it entirely possible for the lowest-priority PBI in the Sprint Backlog to be the one of greatest value to the PO. For example, the most valuable PBI may have technical dependencies upon other PBI's in the Sprint. The Development Team may reasonably plan to action the dependencies first, and so those items will consequently be given higher priority in the Sprint Backlog.

If the team discover that they are unlikely to deliver the "lowest priority" PBI in the Sprint, the decision of what to do will therefore depend upon its associated value. If the PBI is essential to the Sprint Goal then the PO may decide to cancel the Sprint. Alternatively, replanning may be possible which will still allow the Goal to be met. In all cases where the delivery of agreed value is concerned, the Product Owner must be consulted.

> I would leave the item(s) in the Sprint backlog itself.

I'd be inclined to return them to the Product Backlog as undone work, and to maintain the Sprint Backlog as the team's genuine current plan.

At scale, this would potentially allow any other teams drawing from the same Product Backlog to progress the items instead.

I think the sprint backlog should remain unchanged until the end, and the items are not completed will be declared in the sprint review.
This way I can not alter the velocity data and have the data for possible comparisons between different sprint and especially analyze why some items were not completed during the sprint retrospective. At the end of the sprint will address the items in the sprint later, or may have in the meantime undergone a reduction of the business value and then sorted with lower priority.

The real question is why the team realizes that started to sprint can not complete the job? The items are not completed perhaps were not addressable, so they had a value in storypoint too high? This is an analysis of sprint retrospective.

At the end of the sprint, the increment must be done.

If the low priority items don't affect the definition of "done" then these items can go back to the PB or to the next sprint.

However, I would keep the items in the sprint backlog because after a few days the development team may see that they can in fact implement these items too, during the current sprint.

Whatever the decision, if some of the items in the sprint backlog will not be addressed in the current sprint, the PO should be consulted as he should agree that the "done" is not affected.