top of page

What happens to Product Backlog Items that you can’t complete by the end of the Sprint?

Updated: Nov 26, 2022

The Sprint Backlog is created at the Sprint Planning event in Scrum.

The purpose of the Sprint is to deliver a ‘Done’ increment which meets the Sprint Goal at least once per Sprint. At the Sprint Planning event, the Product Owner and the Scrum Team collaborate together to create a Sprint Goal - which describes why the Sprint is valuable - after which the Development team selects Product Backlog Items which describe what will be delivered and creates a plan for how to deliver them.

The Sprint Backlog artifact in Scrum contains the Sprint Goal, the list of Product Backlog items selected for the Sprint plus the plan for delivering a done increment by the end of the Sprint.

Determining how much work can be done during a sprint can be challenging - especially for newer Scrum Teams. It sometimes happens that during the Sprint, the Developers realize that they are not on track to deliver all of the Product Backlog Items selected for the Sprint, either because the work was more difficult than anticipated or due to changing circumstances during the Sprint or for some other reason. If this happens, the team may decide to remove lower ordered Product Backlog Items from the Sprint in order to allow the team to focus on delivering the Product Backlog Items which are most valuable to the Sprint Goal.

If this happens, then the team should return any uncompleted Product Backlog Items to the Product Backlog.


  • Business priorities may have changed, and the Product Owner may choose to re-order the Product Backlog which could cause this item to be lower on the list than it was previously.

Product Backlog Items which are not completed by the end of the Sprint should be returned to the Product Backlog; they should not be carried over automatically to the next Sprint.

What your team should not do with incomplete Product Backlog Items

  • Drag the uncompleted work automatically to the next Sprint without disclosing it to the Product Owner and without discussing it at the Sprint Retrospective or Sprint Planning event.

  • Why not? This approach lowers transparency and does not give the Product Owner a chance to determine where to order this item on the Product Backlog

At the Sprint Retrospective event, the Scrum team should discuss what happened during the Sprint. Some common root causes for this situation are as follows:

  • Newer teams may not yet have a good understanding of how much work can be completed in a Sprint.

  • Response: Work on estimation approaches, including the complimentary practice of using points to size work and tracking velocity to determine how much work a team can completed within the Sprint.

  • Product Backlog Items may not have been well refined, or well understood, prior to the Sprint planning meeting.

  • Response: Consider dedicating additional time to refinement activities during the next sprint.

  • The team might not be using the Sprint Planning meeting to best effect; is it fully discussing how it will plan to deliver the work of the Sprint?

  • Response: Consider fuller discussions around the how at the Sprint Planning meeting.

  • The team may not be making full use of the Daily Scrum meeting.

  • Response: Consider modifying the approach to the Daily Scrum meeting to ensure that the team is inspecting progress toward the Sprint Goal and adapting the Sprint Backlog as necessary.

Final thoughts

There are several potential reasons for a team not completing all the Product Backlog Items which were originally planned for the Sprint. Examining why they were not completed and making that transparent is the path to remaining agile and improving as a team. (For ideas on how to deliver a Done increment each Sprint, check out Three Steps to Done in Scrum.)

bottom of page