It seems that the Scrum Guide provides a clear answer to this question. All unfinished work at the end of a Sprint should be returned to the Product Backlog. It appears this could conclude the discussion. But why do I find myself repeatedly explaining to teams how to handle unfinished tasks in Scrum?
Let’s explore the reasons.
One of the main challenges in dealing with tasks unfinished within a Sprint is the teams’ (and stakeholders’) misunderstanding of one of Scrum’s values. Of the five values described in the Scrum Guide, Commitment is often the most recalled.
The problem is that this value is often misconstrued as a developer’s commitment to complete a certain number of tasks within a certain time. This is not in line with either Scrum logic or the Agile mindset. In fact, Commitment implies the entire (this is important) Scrum Team’s obligation to create a valuable Increment to achieve the Sprint Goal. Nothing more, nothing less.
If this means ignoring some tasks in the Sprint Backlog to achieve the goal, so be it. If the team decides that to achieve the Goal, it needs to add some work to the Sprint Backlog, no problem. The object of commitment is the effort directed towards achieving the goal, not specific tasks.
The main takeaway from the above is that unfinished (completely or partially) tasks at the end of the sprint are completely normal for any Scrum Team. There is no need to berate the team in the retrospective for uncompleted tasks. There’s no need to strive for 85-95-100% Committed-VS-Completed.
Developers themselves decide what work needs to be done to achieve the Sprint Goal. If the goal is achieved, it doesn’t matter how many tasks remain in the Sprint Backlog at its conclusion.
What to do with what remains?
Let’s formulate it somewhat differently. The question of “what to do” is quite clearly answered by the Scrum Guide. All unfinished work items must be returned to the Product Backlog. The only thing left is to figure out how this can be implemented.
A good idea, in my opinion, is to decide at the Sprint Review which of the unfinished has not lost its value. And then return to the Product Backlog only what makes sense to complete in the future. This is important! Do not turn the Product Backlog into a “ship graveyard.” My experience proves that a significant part of the undone tasks from the current sprint loses meaning at the moment of the Increment’s delivery. But often the PO and stakeholders are reluctant to give them up. This passion for accumulating things that are not very necessary must be overcome.
The stories returned to the Product Backlog have a chance to enter the Backlog of a new Sprint, but this will only happen if they can be linked with achieving a new Sprint Goal. It is also possible that these stories will be modified and reinterpreted in the process of Backlog Refinement and become part of other sprints.
But I will repeat this again and again:
- A Scrum Team has no obligation to complete all the work planned at the beginning of the sprint in the current sprint!
- A Scrum Team has no obligation to finish in the new sprint all the work unfinished in the past sprint!
- A Scrum Team has no obligation to do anything with unfinished work other than returning it to the Product Backlog (after evaluating whether it’s worth doing).
- Developers decide what and how will be done in the Sprint to achieve the Sprint Goal, guided by the DoD (and AC).