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