Learn to Slice PBIs That Are Unlikely to Be Completed in the Sprint to Deliver Maximum Value and Put the Remaining Slices in the Product Backlog



Stage 4

Agile IQ® Level

Sprint Planning



Although all work may not be completed within a Sprint we want to avoid unfinished work at the end of a Sprint as much as possible. [1] It is desirable that Product Backlog Items (PBIs) assigned to a Sprint are completed within that Sprint. When it is evident this will not be the case, we should alter our plans.

Why We Want to Avoid Incomplete Product Backlog Items

Within the Scrum framework we look to deliver value every Sprint based upon the Sprint Goal. [2] When we fail to do so we introduce further risk of not delivering the intended value, and may fail to deliver against the Sprint Goal.

If we return incomplete PBIs to the Product Backlog at the end of a Sprint, there is a possibility that it will not be selected for future Sprints. This would be a form of waste (cost without value).

Return Incomplete Items to the Product Backlog

At the end of a Sprint we return any work items to the Product Backlog. [2] The item is re-estimated based on the remaining effort to complete the item and is prioritised with out Product Backlog Items. The Product Owner is then in a position to decide if the work item is still a priority and part of the next Sprint Goal.

The team should not include incomplete work as part of their velocity. [3] Scrum is focused on delivering value in an incremental manner. Incomplete work has not delivered value. This should not be seen as “punishing” the team but rather reinforcing the importance on the incremental delivery of value.

Can Value Still Be Delivered Within the Sprint?

Team members can communicate concerns about incomplete work items in the Daily Scrum or in other team meetings. With enough notice, the scope or requirements may change with the endorsement of the Product Owner such that the work item is completed within the Sprint (and value is delivered) with a diminished scope.

The Daily Scrum is a mini planning event for the team as the purpose is to “inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work”. [2] It is not a status report meeting. Team members should communicate any concerns they have with deviations from the planned work in the Sprint Backlog and the Sprint Goal. It should not be left until the end of the Sprint for the Product Owner to be notified that the Increment may not be delivered.

Although we seek to avoid scope change during a Sprint, change is inevitable. The focus should remain on achieving the Sprint Goal.


Use retrospectives for the team to reflect upon why a work item could not be completed within the Sprint. It may uncover other issues such as having too much work in progress, unclear priorities, a poorly defined Sprint Goal, overcommitment, unreliable estimates, or other causes.

Things to watch out for

  • People tend to be overly optimistic in completing work. Build a supportive culture that encourages team members to speak up when work is not going as planned.
  • Insufficient reflection and action may led to ongoing overrun of work items.
  • Product Owners may be unhappy with unmet goals. Manage their expectations with timely communication and transparency.
  • Persistent overruns may be overlooked and become “business as usual”.

Actions to try

  • Encourage and praise team members who bring to light issues rather than try to conceal them.
  • If faced with incomplete work, the team should propose options to the Product Owner (rather than simply inform them that the Increment will not be delivered).
  • Depending on the nature of the inability to complete the Increment, the Product Owner may cancel the Sprint if the Sprint Goal becomes obsolete. [2]


1. Cohn, M. (2014) Unfinished Work at the End of a Sprint is Not Evil. https://www.mountaingoatsoftware.com/blog/unfinished-work-at-the-end-of-a-sprint-is-not-evil

2. Sutherland, J. & Schwaber, K. (2020) The 2020 Scrum Guide (TM). https://scrumguides.org/scrum-guide.html

3. Cohn, M. (2015) Handling Work Left at the End of a Sprint. https://www.mountaingoatsoftware.com/blog/handling-work-left-at-the-end-of-a-sprint

agile iq academy logo 2022-05-05 sm

Enter your details

search previous next tag category expand menu location phone mail time cart zoom edit close