Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Move PBI from sprint backlog to product backlog mid-sprint

Last post 11:40 am January 27, 2015 by Razvan Mocanu
5 replies
04:47 pm January 23, 2015

In the scenario where a team knows mid-sprint that they 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? Why would you move the the PBI mid-sprint versus just waiting until the end of the sprint? What are the pros and cons?

I'm asking as I've encountered differing opinions within my team.

12:02 am January 24, 2015


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...


04:12 am January 24, 2015

>...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.

04:42 am January 24, 2015

> 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.

05:09 pm January 26, 2015

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.

11:40 am January 27, 2015

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.