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.
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. If your team is consistently not able to complete a significant amount of work during the Sprint, this should be discussed at the Sprint Retrospective event.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.