团队效率是否在逐渐提升，让数据来说话

在我们的 Scrum 中，最常涉及到的是以下几个数据：

时间盒

时间盒定义了 Sprint 的长度，有良好节奏的团队的时间盒应该是恒定不变的，Scrum 的建议是在 2 - 4 周里选一个时间固定下来，我们选择以 2 周为一个 Sprint，用简易的最小值，是为了可以更及时地去调整。我们实践下来发现，CI/CD 等基础设施不成熟的团队，时间盒适当长一些，Sprint 的产出会更高，毕竟回归测试、版本发布是每个 Sprint 中不可缺少的部分。

下图是我们一个团队的时间盒图，可以看到，团队在经历过初期 3 个凌乱的 Sprint 后，从第 4 个 Sprint 开始，非常好的控制了时间盒，整个团队后续的每个 Sprint 都很有规律，这样团队的节奏感非常强。

timgboxing

故事点

这个概念不用多说，大家都了解，我们借鉴了《硝烟中的 Scrum 和 XP》里「理想化人天」的方法，让故事点有一个「摸得着」的参考依据，也方便关联其他（实际可用人天等）数据，团队在 Planning 上出牌的时候，更容易给出故事点的数值。在 Planning 上，团队会确定本次 Sprint 计划完成的故事点数，回顾会上，会得到本次 Planning 实际完成的故事点数。 下图是我们一个团队的计划故事点和实际完成故事点的柱状图，可以看出，团队的计划性越来越好，完成的故事点越来越接近于计划的故事点。

story-points

实际可用人天

这个数据很简单但必不可少，有了团队人数 P，时间盒 T，成员请假总人天数 O，便可计算出实际可用人天 D = P * T - O

投入度

有了上述几个数据，投入度自然就出来了，投入度 = 实际完成故事点点数/实际可用人天。投入度反应了整个团队的效率。下图是我们一个团队的投入度曲线，可以看出，整个团队效率整体是上升的。有了投入度这个数据，团队才可以比较合理地预测下一个 Sprint 预期能完成多少故事点，也方便 PO 准备 Planning 的内容。

percentage

Sprint 计划

我们在 Sprint 开始时，还会有一个数据模版被填充，这些数据告诉团队和整个公司，当前 Sprint 的节奏和重要时间点，以便所有人知晓，如下：

extra-data

尾声：很多对敏捷转型犹豫的人会问，转为敏捷开发以后，如何来证明团队效率更高，交付了更多有价值的产品功能？上述这些数据可以说明一切，让数据说话，是最真实的答案。

强烈推荐《硝烟中的 Scrum 和 XP》一书，团队人人必看。

参考资料

《硝烟中的 Scrum 和 XP》https://www.infoq.cn/article/scrum-xp-from-the-trenches