“We do Scrum but our Sprint Backlog is fixed”
Are you serious? — episode 6
There are several anti-patterns related to the Sprint Backlog that raise eyebrows. One of them is this:
The Sprint Backlog is fixed during the Sprint.
I have witnessed the following scenario very often:
- The Scrum Team plans the Sprint and determines that items A, C, E, G and K are put on the Sprint Backlog.
- Mid Sprint — Item A and C are finished — the team receives additional information. With this new information item F has the highest value of all items. It is critical to have it finished as soon as possible.
- The Development Team informs the Product Owner that the item can be picked up in the next Sprint. They don’t even consider ‘breaking the Sprint’. It is considered bad planning to change the Sprint Backlog.
Anti-pattern
In my experience this scenario is very common. It’s an anti-pattern to leave the Sprint Backlog unchanged during the Sprint.
Here is what the Scrum Guide says about changes during the Sprint:
“No changes are made that would endanger the Sprint Goal” — SG
It doesn’t say changes are not allowed. It says changes are only not allowed when they endanger the Sprint Goal.
The Scrum Guide then says:
“Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.” — SG
So, taking the example I used: the team learned that item F should be implemented as soon as possible to meet the Sprint Goal. The Development Team and the Product Owner will now negotiate if and how to best incorporate item F. They could opt to drop E, G and/or K. They could also choose to add item F to the top of the Sprint Backlog as an additional item, while keeping E, G and K on the backlog as well. Or any other scenario. In the end the Development Team decides how the Sprint Backlog will be changed.
Additional ammunition to showcase it’s an anti-pattern
During Sprint planning:
“The Development Team works to forecast the functionality that will be developed during the Sprint.” — SG
The Sprint Backlog is a forecast. This means that it can change. It is not a commitment.
The section in the Scrum Guide about the Sprint Backlog artifact repeats that it is a forecast. It then adds:
“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.” — SG
This is completely covering the example in this article. The Development Team learned more about the work required to reach the Sprint Goal. They learned that item F has higher priority and as a result they should discuss with the Product Owner how to alter the Sprint Backlog.
Sure changes will have an impact. Additional alignment and discussion is required, which will influence the team’s predictability and capacity. You seriously need to consider if this is worthwhile with every proposed change.
Having said this: it is also a mindset. One of the teams that I have worked with saw scope changes as a given. They knew that as more was learned almost every Sprint turned out to be different than expected at the planning. It liberated them. Their capability to adapt to the new truth made them a very successful team.
Closing thought
We determined that the Sprint Backlog is not fixed. However, there is a catch. The Sprint Backlog can only be altered when this doesn’t endanger the Sprint Goal. This makes it so important to spend your time to have a serious Sprint Goal. It shouldn’t be: ‘The Sprint Goal is to finish items A, C, E, G and K’. But that’s a topic for another article.
Join us on Slack!
We run a Serious Scrum channel on Slack. You’re all invited. Feel free to connect with us on Slack to share your thoughts. Also if you are interested in publishing in Serious Scrum.
Thank you for taking your time to read seriously.
My twitter profile is https://twitter.com/WJAgeling