Scrum Myth: The Sprint Backlog is a Commitment
This blog 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 as to 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 realise the Sprint Goal
- A forecast of functionality in the next increment
- A forecast of the work required
- An artefact 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 & the Product Owner have to be able to discuss the work in the Sprint Backlog so that the overall Sprint Goal which is the true aim of the Sprint is realised.
This element that has evolved into the Sprint Backlog being the committed plan is linked to the disconnection in understanding of the work estimate. When given between a Development Team and a Manager in relation to an amount of work that may or may not be achievable.
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.