了解你的 Scrum 团队的实际开发速度是非常多敏捷团队的诉求,而速度(Velocity)作为敏捷项目的度量工具,为管理者提供了对团队工作能力深入了解的机会。
这份指南将深入探讨 Scrum 中速度的概念,指导你如何进行计算,并演示如何利用这个强有力的度量工具来预测团队将来的性能表现。
Scrum 中的速度是什么
在 Scrum 及其他敏捷项目管理框架中,速度被用作一个敏捷度量工具,以估计 Scrum 团队在给定的时间框架内,通常是一个冲刺(Sprint)周期可以完成的工作量。
速度可通过故事点来表示,故事点是衡量用户故事或任务大小的单位,反映了其复杂性、风险和不确定性。故事点提供了一种比基于时间的度量(如小时或天)更为精细的估算工作量的方法。
举个例子,假设有一个开发应用程序登录界面的用户故事。团队可能会根据这个任务的感知复杂度和完成所需的努力,将其故事点值定为3。而集成一个复杂的支付网关由于其更高的复杂性和潜在风险,可能被评估为8故事点。
每位团队成员在两周的冲刺期间能完成的故事点数受到多种因素的影响,包括个人的经验、任务的复杂性以及团队的工作动态。新成立的 Scrum 团队通常每人每两周冲刺的平均故事点在5到10之间。
速度有助于预测团队在未来冲刺中能够实现的持续改进,这对于规划和设定现实目标至关重要。这一指标帮助团队建立稳定的工作节奏,预测项目的时间线,并管理利益相关者的期望。
如何计算 Scrum 中的速度
通常在每个冲刺的末尾,通过汇总所有完全完成的用户故事的故事点或其他测量单位来计算速度。这里是如何在Scrum中计算速度的分步骤过程:
规划冲刺
在冲刺开始前,为产品待办列表中的所有用户故事确定并分配点数。例如:
-
分配用户验证:5点
-
添加支付网关集成:8点
-
实现搜索功能:3点
-
开发用户资料页面:13点
-
实现邮件通知:2点
-
优化数据库查询:21点
-
创建管理员控制台:5点
团队应当基于过去冲刺的平均速度和其它因素(如假期或外部依赖情况)来承诺在下一个冲刺中完成的用户故事。例如,若平均速度为15点,并且没有假期或外部依赖,那么团队可能承诺在下一次冲刺中完成总共大约15点的用户故事。
列出已完成的用户故事
在每个冲刺末尾,构建一个完全完成的用户故事列表。这些故事应该已经满足了验收标准,并得到 Scrum Master 与产品负责人评审的故事。
如果用户故事完成度达到90%,则不能视为完全完成的工作。团队应将其转移到下一冲刺,并基于剩余工作重新评估其故事点数。
核对点数
团队应该已经为每个已完成的用户故事分配了故事点数。如果由于某些原因需要重新评估故事点数,就应该立即和团队一起进行故事点变更。
例如,假设团队在当前冲刺中完成了三个用户故事:分配用户认证、添加支付网关集成和实现搜索功能。这些任务可分别分配如下故事点数:
-
分配用户认证:5点
-
添加支付网关集成:8点
-
实现搜索功能:3点
总结故事点数以计算速度
接下来,团队需要将所有已完成的用户故事的故事点数相加。故事点数的总和表示迭代速度。
在上述情况下,总和将是5个故事点 + 8个故事点 + 3个故事点 = 16个故事点。因此,这个迭代的速度将是16个故事点。
计算平均速度
通过计算团队完成的迭代数量的平均速度,就可以获得更可靠的未来迭代度量。这个度量方法对于新组建的团队或规模或结构发生变化的团队特别有用。
例如,如果过去三个迭代的速度分别是14、16和15,那么平均速度将是(14 + 16 + 15) / 3 = 15个故事点。
可能影响 Scrum 速度的因素
有许多种因素可以影响 Scrum 指标和速度。了解这些因素可以帮助规划和持续改进团队的表现。
团队规模和技能水平
团队中的人员数量和他们各自的技能水平可能影响团队在迭代期间完成的工作。一个较大的团队可能能够在一个迭代中完成更多的故事点。然而,人数的增加可能会导致高额的沟通成本和协同效率下降。
相反,一个小而技能水平高的团队可以通过高效处理复杂任务来超越一个规模较大、技能水平较低的团队。
团队的稳定性和经验
当Scrum团队成员在连续几个迭代周期内协作时,他们可能会克服那些通常会阻碍新成立团队的问题。他们会形成有效的沟通模式,并清楚地知道各自的强项。
团队成员间的共享经验成为解决问题的宝贵资源。这种彼此间的熟悉感能够显著提升团队的工作效率。
用户故事的复杂性
包含复杂故事的冲刺通常会导致效率降低。如果这些复杂性并未在分配的故事点数中得到准确体现,那么效率的数值会产生误导。
为了维持稳定的效率,一些团队努力在一个冲刺周期内平衡简单快速完成的任务和更为复杂的任务。
外部依赖和限制条件
如果迭代团队依赖另一个团队来完成数据库更新或 API 集成,而该团队延迟了交付,这将直接降低迭代团队的速度。通过有效的团队间沟通,了解这些依赖关系并为其进行计划,可以减轻对速度的负面影响。
同样,将公共假期或强制性公司活动考虑到迭代计划中也是必要的,因为它们会减少实际的工作时间。
速度在 Scrum 中的应用
一旦掌握了团队的工作效率,它便成为冲刺计划和项目管理多个方面的有力工具,具体包括:
预估未来冲刺:通过了解团队的平均工作效率,可以去除猜测的成分。例如,如果团队在过去三个冲刺中的平均工作效率为50故事点,则可据此为下一个冲刺做出基于数据的规划。若下一次冲刺的工作量约为50故事点,则代表了一个合理的承诺。
预测项目时间线:与猜测或希望相比,利益相关者更倾向于依据数据驱动的估计。假设项目待办事项总共200故事点,且团队平均每个冲刺可完成50故事点,那么可以自信预测团队大约还需四个冲刺完成项目。
识别过度承诺与承诺不足:团队效率的突然下降至30故事点或激增至70故事点是警示信号。效率持续下降可能表示团队感到压力过大,而效率上升可能意味着团队成员面临的挑战不足。这些信息使得可以实时进行调整,例如重新分配任务或重新考量冲刺目标。
追踪改进与迭代进展:随时间追踪效率有助于判断团队是否变得更加高效或是存在需要关注的持续问题。若效率从40增加到60,表明流程改进正产生效果。
利用 PingCode 跟踪速度
PingCode 产品中包含一个速度图表,显示团队过去的速度,使计划迭代更加容易。这是一个一站式工具,可以可视化团队可以处理多少工作量,让团队能够设置更准确的未来迭代目标。
此外,它还提供了所有其他敏捷度量、洞察、报告和项目管理功能,帮助团队将计划和绩效提升到更高水平。
Scrum 中的速度:常见问题
Scrum 中的速度与生产力是否相同?
Scrum 中的速度与生产力不同。速度是一个用于计划和估算团队在未来迭代中可以处理多少工作的指标。生产力通常是一个更广泛的度量,可以包括工作质量、流程效率和对业务的价值等因素。
如何提高团队的速度?
团队可以通过定期举行回顾会议来改善速度,讨论哪些做得好和哪些做得不好,并计划下一个迭代的改进。常见改进项目包含:增加沟通和反馈的频率、减少上下文切换、减少在不同任务或项目之间频繁切换,这些都可以提高速度并保持更一致的效率。
使用 Scrum 中速度的限制是什么?
虽然速度是一个有用的规划工具,但它也有限制,它并不应该是评估团队表现的唯一绩效指标。为了更全面地了解团队表现,可以考虑跟踪其他敏捷指标。
其中一个重要的限制是,速度不能衡量工作质量或交付的商业价值。它只是一个定量指标,无法考虑个体用户故事复杂性的定性因素。
速度是团队特定的,它不能用于比较不同团队的表现。团队内的每个小组可能有不同的工作方式,导致速度的差异。较高的总体迭代速度并不意味着一个团队比另一个团队更成功。
推荐阅读:
Scrum 开发指南: Scrum 框架详解 | Scrum 四个会议及正确召开方式 | 正确的计划和执行Sprint的方式 | 做好迭代计划的4大关键点 | 做好这4点让每日站会更适配敏捷团队 | 开好迭代评审会的3个关键步骤 | 为什么要召开迭代回顾会 | Scrum 3大角色及其岗位的具体职责 | Scrum三大工件在敏捷开发中的作用 | 2022年14个最佳 Scrum 敏捷项目管理软件 | 更多
Kanban 敏捷指南: 使用看板(Kanban)管理方法的5大好处 | 看板 VS Scrum:如何选择? | 看板和 Scrum 的混合模式适合在哪些场景使用 | 更多
规模化敏捷: 规模化敏捷的价值及五大规模化敏捷框架 | 规模化敏捷之 Spotify 模型 | 规模化敏捷框架之LeSS框架 | SAFe 规模化敏捷框架 | Scrum@Scale 模型 | 敏捷项目组合管理 | OKR与敏捷开发 | 更多
产品管理: 如何构建合格的产品路线图 | 如何成为一个优秀的产品经理 | 敏捷路线图的重要性以及构建 | 如何构建简单有效的产品需求文档 | 利用 NPS 确定功能优先级 | 每个产品经理都需要了解的产品分析技能 | 更多