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