如何衡量scrum团队的sprint冲刺速度?你需要明确定义「速度」

在非正式谈论它时,我将「速度」定义为衡量团队进展速度的一个指标。在大多数情况下,这个定义非常有效。然而,它会对计算scrum团队速度时应该考虑的一些细节产生混淆。这种混乱的出现是因为确实有两种更精确的速度定义方法。让我们看看它们是什么。

 

1)速度衡量团队在sprint中提供的功能。

2)速度衡量团队在sprint中将想法转化为新功能的能力。

 

听起来可能一样,然而它们略有不同。假设你跳进河里开始游泳。一小时后,你可以测量你游泳的距离——在距您开始的地方2公里。在敏捷方面,如果游泳冲刺是一小时,我们可能想要称之为你的速度,并说你每小时或每次冲刺游泳2公里。

 

但是,如果你游泳时,河流以每小时一公里的速度向你流动怎么办呢?在那种情况下,你真实游了3公里。根据河岸测量,你只移动了两公里的物理距离。但是在向前走两公里的路上,你克服了在河边一公里处被推倒的情况。

 

那么,你的速度是哪个?如果我们使用我们的第一个定义 - 速度是一个团队在冲刺中交付多少 - 那么速度就是2KM。这名游泳运动员取得了2公里的进步。

 

如果我们使用我们的第二个定义 - 速度是将想法转化为新功能的能力 - 那么速度就是3。这位游泳运动员有能力在每个冲刺中提供3公里的进度,我们会看到他在没有电流而不是河流的湖中游泳。

 

要了解这在敏捷项目是如何应用的,考虑一个问题,一个团队是否应该因为在冲刺期间因为「修复错误」而获得速度信用。使用速度来衡量sprint中提供的功能的团队不会因错误修复而获得奖励。没有提供新功能。所以没有积分。

 

另一方面,一个团队使用定义速度作为将想法转化为功能的能力,将声称错误修复是值得的。他们的逻辑是,花在修复bug上的时间可能是用来添加新功能的,除了产品所有者为他们优先安排不同的工作。

 

对于许多团队而言,这两个定义将产生相同的值。对于那些没有获得速度信用的团队来说,价值观差异最大 - 通常团队会做很多错误修复或进行大量重构。

 

在速度的定义上,这些细微的差异并不总是比另一个更好。你所使用的方法在很大程度上取决于你希望通过测量它来学习什么,以及你对未来的期望。

 

如果你期望未来和今天一样,也就是说,团队将花费与现在一样多的时间进行错误修复、重构等工作,那么使用速度作为衡量前进进度的指标将是你正确的答案。

 

但是,如果您期望未来会有所不同,那么大型重构和修复bug的时间将很快结束,那么您可能希望将Velocity定义为团队将想法转化为功能的能力,然后将这些活动的要点添加到Velocity中。

 

最重要的是与团队中的每个人(包括产品所有者和ScrumMaster)澄清,当他们使用“速度”这个术语时,您的团队想表达的什么意思。有了一个精确的定义,很容易回答在测量速度时应该算什么的问题。

其他