Scrum——图片111

死磕 Sprint Backlog,真的好吗?

什么是“死磕”?

展开今天的谣言澄清之旅之前,解释下“死磕”这个词,官方释义为:和某人或某事作对到底的意思,近现代多表示未不达目的不罢休,来源于北京话。

不过我个人对这个词更多的了解是来自于南京普通话,大家有任何关于这个词的见闻,请打在留言区。

死磕“Sprint Backlog”

唠嗑了这么久,我们回来说说为什么死磕“Sprint Backlog”是一个误解呢?在我所经历的大多数团队的敏捷实践中,大家总喜欢把承诺作为工程师团队的优秀品质之一,从而衍生到承诺完成所有工作量更是一个工程师高尚的必备素质。

如果没有完成Sprint Backlog里的工作,就是工作不努力,绩效有问题的表现,甚至在回顾会里大家会着重讨论为什么没有完成工作量。说到这里我想大家是不是开始意识到这个逻辑是有问题的了。那我们先看看在Scrum指南上是怎么描述Sprint Backlog的?
微信截图_20220428174046
简单来说,Sprint Backlog是动态可变的,一切都是为了完成Sprint Goal。所以如果在每个Sprint里有且只有一个不能变的那就是Sprint Goal。
微信图片_20220428172114
唯一不变的追求是Sprint Goal

我们在项目里用敏捷用Scrum的最重要原因是用积极的变化去应对多变的环境,在每个Sprint计划会里确定的内容,只有在每天的工作过程中发现并验证其准确性。一旦发生变化,我们需要在不影响Sprint Goal的前提下,立即马上对我们的工作计划进行调整,有的时候甚至是颠覆。

作为无所不能的工程师,我们承诺的不是已经计划好的工作量,而是尽力去追逐高价值的事物,尽力去支持我的队友,尽力去完成高质量的交付,尽力去挑战更难的问题。

比如在一个真实的案例中,某一项需求可以立即带来客户的回报,但是团队承诺了要完成这些工作(KPI),所以团队的选择是继续把手上的工作做完,而不是投入到给公司带来更多更大价值的事情上。

最后的结果就是团队完成了迭代KPI,但是丢掉了一个大客户。所以这里也给各位老板提个醒,切不可把完成Sprint Backlog作为团队的绩效指标。

我们要死磕什么?

所以,当我们面对变化时,我们需要遵循以下原则:

1)   高价值优先(价值为王)
2)   迭代中用“渐近明细”的原则(精准的需求往往是在尝试中涌现的)
3)   拥抱变化(好事情啊,练功练错了还不赶紧改,莫非要走火入魔了再回头吗)

最后,让我们用死磕“高价值高质量交付”来代替死磕“Sprint Backlog”吧!

 

 

关于作者:

丁志润(Derek Ding)

企业敏捷转型专家,PMP

Scrum联盟认证 CSM,CSP

Scrum.org认证 PSM I,PSM II,PSM III

大规模敏捷认证 Leading SAFe