Scrum Myth: The Sprint Backlog is a Commitment

In this article, I will look at the myth that has grown around the Sprint Backlog being a commitment of the work that will be delivered in the Sprint. If it is not delivered the team must justify to the Product Owner or manager playing that role why they have not delivered all the agreed work.

Let’s review the Scrum Guide and consider this, and consider what it says the Sprint Backlog is:

• A set of Product Backlog Items that form a plan to realize the Sprint Goal.
• A forecast of functionality in the next increment.
• A forecast of the work required.
• An artifact to make visible all the work the Development Team has identified as necessary to meet the Sprint Goal.

As you read further you can see that it states the Development Team updates the Sprint Backlog regularly. If new work is identified and required, it is added and if work is deemed no longer necessary it is removed.

The Sprint Backlog is not a fixed list of work to be done, it is a living plan by the Development Team on how it will meet the Sprint Goal. It needs to be flexible, and the Development team and the Product Owner have to be able to discuss the work in the Sprint Backlog. This is necessary so that the overall Sprint Goal, which is the true aim of the Sprint, can be realized.

This element, which has evolved to equate the Sprint Backlog with a committed plan, is linked to the disconnection in the understanding of what a work estimate is actually intended to do. 

That doesn’t mean there is no commitment; after all, Scrum has 'Commitment' stated as one of its core values. And you would be right in saying that the Development Team has made a commitment. However, that commitment is to do their best to achieve the Sprint Goal. And where a piece of work may be unachievable then they should, at the earliest possible time, highlight this with the Product Owner and discuss any required adjustments to the Sprint Plan in order to meet the Sprint Goal. 

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.