定义

“估算点数”是Scrum敏捷开发方法中的一个核心概念，用于评估产品待办事项（Product Backlog Items，PBI）的实施所需努力的相对量。它采用无单位的数字进行相对估算，以一项简单的工作项作为基准，以帮助团队更准确地预测和计划工作量。

→更多其它模式请参见《Scrum模式总览》

为何需要

Scrum团队或组织在进行项目计划或迭代计划时，需要对用户故事或产品待办事项进行估算，以便确定优先级，分配资源，制定时间表，评估风险，监控进度等。然而，传统的估算方法，如基于时间或人力的估算，往往存在以下问题：

• 不准确：时间或人力的估算往往受到许多不可预测的因素的影响，如需求变更，技术难题，团队成员的能力和协作，客户的反馈等，导致实际的工作量和进度与估算的结果有很大的偏差。
• 不一致：时间或人力的估算往往受到个人的主观判断和经验的影响，不同的团队成员或不同的团队可能对同一个用户故事或产品待办事项给出不同的估算结果，导致估算的结果缺乏一致性和可比性。
• 不灵活：时间或人力的估算往往受到固定的假设和约束的限制，如每天的工作时间，每个人的工作效率，每个任务的依赖关系等，导致估算的结果缺乏灵活性和适应性，难以应对项目的变化和不确定性。
• 不有趣：时间或人力的估算往往是一种单调和枯燥的活动，缺乏创造性和参与感，导致团队成员对估算的过程和结果缺乏兴趣和信心，影响团队的士气和动力。

何时使用

估算点数是Scrum团队常用的估算方法。
尤其是当项目的需求或范围不是很明确或容易变化时，并且需要快速而准确进行估算，更推荐使用估算点数。

如何使用

• 估算时机：对产品待办事项的估算，通常在产品待办列表梳理会上进行

• 估算过程：

  • 选取中小规模的待办项作为基准，将点数设置为2或3
    基准待办项在整个产品开发过程中最好保持不变
  • 使用计划扑克法进行估算
    1. 选取待估算的待办项
    2. PO解释待办项，并向开发团队答疑
    3. 开发团队每个人进行独立估算，并选好扑克
    4. 开发团队所有人同时亮出自己的扑克
    5. 如果估算结果差别较大，则进行讨论
    6. 重复以上过程，直到基本达成一致

• 使用估算点数跟踪进度：团队可通过估算点数来衡量Sprint的速率，从而更好地计划和调整工作。

注意事项

1. 不要在团队间比较：估算点数不是绝对的，而是相对的，它们只能在同一个项目或同一个团队之间进行比较和使用，不能跨项目或跨团队进行转换或应用，因为不同的项目或不同的团队可能有不同的估算单位和范围，以及不同的估算方法和工具。
2. 不要只估算下个Sprint的工作：尽量对产品待办列表中的所有工作项进行估算。这种做法有助于产品负责人和团队更好地理解整个产品的工作量和优先级。这种全面的估算使团队能够对未来的工作有更清晰的预期，并有助于长期规划。
3. 全员参与：确保开发团队成员全员参与估算过程，避免个别成员的过度影响。
4. 定期审视和调整估算方法：根据团队的实际情况和经验，定期审视和调整估算方法。
5. 透明沟通：与利益相关者保持沟通，确保他们理解估算的方法和结果。

案例研究

案例背景

一家从事互联网金融服务的创业公司，拥有一个由9人组成的敏捷开发团队，使用Scrum框架进行项目管理。团队的产品负责人（PO）是李明，Scrum Master是王华，开发团队7人。

案例过程

在开始一个新的项目之前，PO根据客户需求和市场分析，创建了一个产品待办列表（Product Backlog），包含了一系列的用户故事（User Story），每个用户故事都描述了一个具体的功能或需求。为了让团队能够更好地理解和估算这些用户故事，PO和Scrum Master决定采用估算点数的模式，使用故事点（Story Point）来表示用户故事的复杂度和工作量。

PO邀请团队成员参加一个估算会议（Estimation Meeting），在会议上，Scrum Master首先向团队介绍了估算点数的基本概念和原则。
接下来，PO逐个展示了其他的用户故事，并让团队成员根据参考的用户故事来估算它们的故事点。为了保证估算的公平和有效，团队采用了计划扑克（Planning Poker）的方式进行估算，即每个团队成员都有一副扑克牌，每张牌上都写有一个故事点的数值，当PO展示一个用户故事时，每个团队成员都要从自己的牌中选出一张代表自己的估算，然后同时亮出来，如果所有人的估算一致，就采用这个数值，如果有不同的估算，就让估算最高和最低的两个人分别说明自己的理由，然后重新估算，直到达成一致。

在估算的过程中，团队遇到了一些问题和挑战，比如：

• 有些用户故事太大或太模糊，导致团队成员无法给出一个合理的估算，这时PO就要对这些用户故事进行拆分或细化，使之变得更清晰和可执行。
• 有些用户故事涉及到一些新的技术或需求，导致团队成员对其复杂度缺乏信心，这时PO就要和团队成员一起进行一些调研或原型设计，以降低不确定性和风险。
• 有些用户故事的估算存在较大的差异，导致团队成员难以达成共识，这时PO就要引导团队成员进行充分的沟通和讨论，以消除误解和偏见，找到一个合理的折中方案。

经过几个小时的估算会议，团队最终为所有的用户故事都分配了故事点，这些故事点反映了团队对用户故事的复杂度的共同认识，也为后续的迭代计划和进度跟踪提供了一个重要的参考依据。

案例效果

通过使用估算点数，该公司的敏捷开发团队取得了以下的效果：

• 提高了团队的估算能力和准确性，使团队能够更好地预测和控制项目的工作量和进度。
  增强了团队的协作和沟通，使团队成员能够更多地参与和贡献自己的意见和经验，也能够更好地理解和尊重其他人的观点和想法。
• 优化了产品的质量和价值，使团队能够更清楚地识别和处理用户故事中的风险和不确定性，也能够更有效地拆分和细化用户故事，使之更符合用户的需求和期望。

Scrum模式：估算点数