We do Scrum but…

“Scrum — Our Sprint Backlog is seen as commitment”

Are you serious? — episode 8

Many people have a hard time with Scrum. One of the most painful issues is how the Sprint Backlog, created during the Sprint Planning, is seen as a commitment of the Development Team. And then commitment is perceived as ‘signed with blood’. This results into the following possible anti-patterns (these are examples from several teams):

• The Sprint ‘fails’ when one or more items planned to be delivered aren’t finalized.
• Stress levels go up towards the end of the Sprint. People are working overtime to finish the items.
• The Development Team will only plan for 50% or less of their capacity to avoid failing the Sprint.
• New items that -due to additional insights- are considered to be more important than those that were planned at the Sprint Planning will not be picked up.
• Items that are no longer relevant are not being dropped because these items are part of the commitment.
• The Sprint succeeds when all items are delivered, regardless of the fact that these items may have become irrelevant due to new insights.
• The Sprint Goal is made irrelevant. The only thing that counts is delivering all the items.

People might find all of the above normal for Scrum. It isn’t.

“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.” — Scrum Guide 2017

It is a forecast, not a commitment of the expected functionality and the work needed to deliver this.

“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.” — Scrum Guide 2017

Here it becomes clear that the Sprint Backlog is not set in stone. The team works towards meeting the Sprint Goal, not towards delivering all items as planned. This is a subtle difference. You may meet the Sprint Goal while you change the Sprint Backlog.

You might say:

“Isn’t ‘commitment’ one of the Scrum Values?”

“People personally commit to achieving the goals of the Scrum Team.” — Scrum Guide 2017

Yes. A commiment to meet the Sprint Goal, amongst other team goals. But — and this is key — commitment is not a guarantee. As sjoerd kranendonk nicely summarized our exchange of thoughts on this item:

“It means doing your best to succeed within reason AND inform involved parties when important insights emerge.

It takes openness & courage, shows respect & is strengthened by focus.” The remaining four Scrum Values.

There is nothing wrong with going the extra mile to make sure that items are finished. Occasionally. But when this becomes a pattern, when it happens every time then there is something wrong.

As Sjoerd Nijland puts it like this:

“Scrum knows no working hours. The team doesn’t commit to working hours but to goals. Teams self-organize, so they determine how they work and if they are going to work overtime.”

“The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint.” — Scrum Guide 2017

Here the Scrum Guide hints towards avoiding anti-patterns like working overtime structurally. Personally I would have loved a stronger statement about sustainable pace, but the Scrum Guide brings forward self-organization and making it enjoyable. Here you find my case for sustainable pace:

Does Scrum protect your team from burning out?

But more importantly: it can always happen that the Sprint Goal won’t be achieved. In that case the Scrum Team should take the opportunity to inspect and adapt. True empiricism. Typically it is not the end of the world when the Sprint Goal is not achieved because the team works in short iterations and as such can respond quickly.

Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.

Do you want to write for Serious Scrum or seriously discuss Scrum?

Thanks sjoerd kranendonk and Sjoerd Nijland for your insights and feedback.