July 11, 2021

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

The purpose of the Sprint is to deliver a ‘Done’ increment which meets the Sprint Goal.  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 can happen 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 so that this item is lower on the list than it was previously. 

PBIs which are not 'done' should be returned to the Product Backlog.

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.

 

About Mary IqbalMary has 10 years of Scrum experience and has worked with Fortune 500 companies in the United States to lead new technology roll-outs and double business revenue.  Mary’s real-world tactical experience and team management strategies have helped businesses achieve accelerated growth through applying the Scrum framework.