Is it really good to smash the Sprint Backlog?

What is "dead knock"?

Before embarking on today’s journey of clarifying rumors, let’s explain the word “死打”. The official definition is: to fight against someone or something to the end. In modern times, it often means not to give up until the goal is achieved. It comes from Beijing dialect.

However, I personally know more about this word from Nanjing Mandarin. If you have any knowledge about this word, please write in the message area.

Slam "Sprint Backlog"

After chatting for so long, let’s talk about why it is a misunderstanding to “Sprint Backlog”? In the agile practice of most teams I have experienced, everyone always likes to regard commitment as one of the outstanding qualities of the engineer team, and it is derived that the commitment to complete all workloads is a noble and necessary quality of an engineer.

If the work in the Sprint Backlog is not completed, it means that the work is not working hard and the performance is problematic. Even in the retrospective meeting, everyone will focus on discussing why the workload was not completed. Having said that, I wonder if everyone is beginning to realize that this logic is problematic. Then let’s take a look at how the Sprint Backlog is described in the Scrum Guide?

In simple terms, the Sprint Backlog is dynamic and variable, and everything is to complete the Sprint Goal. So if there is one and only one that cannot be changed in each Sprint, it is the Sprint Goal.

The only constant pursuit is the Sprint Goal

The most important reason why we use Scrum in agile projects is to use positive changes to deal with the changing environment. The content determined in each Sprint planning meeting can only be discovered and verified in the daily work process. Once there is a change, we need to immediately adjust our work plan without affecting the Sprint Goal, and sometimes even subvert it.

As omnipotent engineers, what we promise is not the planned workload, but to try our best to pursue high-value things, try our best to support my teammates, try my best to complete high-quality delivery, and try my best to challenge more difficult problems .

For example, in a real case, a certain requirement can immediately bring returns to customers, but the team has committed to completing these tasks (KPI), so the team’s choice is to continue to finish the work at hand, rather than investing in giving On things that bring more and greater value to the company.

The final result is that the team completed the iteration KPI, but lost a big customer. So here is also a reminder to all bosses that the completion of the Sprint Backlog must not be used as the team’s performance indicator.

What are we going to die for?

Therefore, when we face changes, we need to follow the following principles:

1) High value first (value is king)
2) Use the principle of “gradual details” in iterations (accurate requirements often emerge from trials)
3) Embrace change (a good thing, if you make a mistake in your practice, don’t change it quickly, do you want to go crazy and go back?)
Finally, let’s replace the “Sprint Backlog” with the “high-value and high-quality delivery”!

 

About the author:

Derek Ding

Enterprise agile transformation expert, PMP

Scrum Alliance Certified CSM, CSP

Scrum.org Certification PSM I, PSM II, PSM III

Large-Scale Agile Certification Leading SAFe