在敏捷项目管理中，团队会创建用户故事来规划即将到来的迭代。 每个故事都详细描述了一个独立的功能，并包含相应的描述和验收标准。
通常，迭代周期持续两到四个星期。 在此期间，团队需要准确评估他们在单个迭代中能够完成的工作量，以确保能在既定的时间内交付成果。
在非敏捷项目中，工作量通常以人天来衡量。 这意味着需要多少全职人员才能完成一项任务。 在这种情况下，制定估算时会同时考虑时间和人力。
但在敏捷项目中，情况有所不同。 估算不再基于时间和人力。 实际上，我们甚至应该避免使用“人天”这样的概念。 相反，团队会为每个故事赋予一个共同认可的数值，以此来代表整体估算。
这个数值的具体含义并不重要。 通常，故事的估算会使用故事点。 这些故事点通常采用斐波那契数列，例如 0、1、2、3、5、8、13、21 等。数列中每个数字都等于前两个数字之和。 这样可以更清晰地区分故事的整体复杂度，因为数值之间的差距会随着数字的增大而加大。
不过，你不必非得使用故事点。 也可以使用 T 恤尺码来估算（如 XXS、XS、S、M、L、XL、XXL）。 甚至可以引入动物来进行估算，比如用不同的动物来代表不同的复杂程度。
关键在于，整个团队都认为哪个数字（或动物）最能代表某个故事的整体复杂度。 这与时间没有任何关系。 最终，团队应该在迭代周期内完成所有计划中的故事。 因此，时间是固定的，是一个常数。
故事点估算的构成要素
故事点估算并非只关乎故事本身的复杂程度或难度。 团队在估算一个故事时，需要综合考虑多个方面，并将它们反映在最终的估算值中。
最终的估算值是一个综合性的数值，它代表了所有相关因素的组合。 以下是估算应包括的内容：
#1. 技术难度
假设我们正在为开发团队估算故事，那么技术难度将是团队首先要考虑的关键因素。
这是一种合理的方法。 技术团队最能评估这类故事。 在这里，团队可以考虑以下几个方面：
- 从技术复杂性的角度来看，这个故事与之前交付的故事相比如何？
- 团队为了完成这个故事，需要创建或修改多少代码文件？
- 这个故事会对现有的系统流程产生多少额外代码修改？
- 算法或逻辑过程的实现有多复杂？
#2. 外部依赖和风险
令人惊讶的是，很多时候，团队迭代中故事的成功取决于其他团队或组织外部人员的贡献。
团队可以独立完成的故事最容易估算。 如果故事需要外部支持，情况就会变得复杂。 因为对于团队以外的人来说，这项活动自然不会是优先事项。 团队必须将这个因素考虑在内，并反映在估算中。
外部依赖性将增加多少估算值取决于团队的经验和“外部性水平”。 通常情况下，团队会逐渐建立一种共识，即对外部人员的依赖会如何影响故事的成功交付。
#3. 可重用性因素
接下来需要考虑的是，团队可以重用多少现有资源来完成故事。 如果某些部分已经存在，那么就没有必要从头开始构建。 相反，团队可以重用已有的解决方案来加速新方案的构建。
这种知识可以降低整体估算值，即使没有这种可重用性，故事本身会更复杂。
#4. 对团队的了解
基于人天数的估算无法考虑的一个重要因素是对团队成员的能力和经验的自我认知。
随着团队的合作和多次迭代的交付，团队成员会互相了解。 他们会逐渐认识到彼此的技能和擅长的领域。 当每个人都了解其他成员时，团队就可以在估算过程中将这些因素考虑在内。
如果一个故事需要团队中非常擅长的特定技能，那么这个故事的实现难度就会降低。 反之亦然，如果整个团队都缺乏所需的技能，那么团队需要更多的时间来学习，并且需要在估算中反映出来。
估算故事
每个故事的估算都应该是团队共同努力的结果。 任何个人都不应该主导故事复杂度的评估。 最终目标是让团队充分讨论估算值，直到所有成员对代表最终估算的单个数值达成共识。
团队可以在迭代细化会议（团队讨论和澄清故事的会议）中直接进行估算，或者可以专门预留时间进行估算。
估算流程示例
- 选择团队使用的估算工具，例如 Planning Poker、Miro board 或类似工具。
- 在白板上写下故事。 让团队讨论与故事相关的想法或问题。 确保整个团队充分了解故事，并准备好进行估算。
- 开始估算。 每个团队成员都从斐波那契数列中选择一个数字。
- 完成所有估算后，共同查看结果。 开始讨论。 通常，团队的估算结果会有两到三个不同的数值。 让估算值较低的成员解释为什么他们的估值应该较低。 然后，让估算值较高的成员详细解释他们的理由。 目标是将所有论点、考虑因素和事实摆在台面上，让整个团队对故事的理解达成一致。
- 讨论结束后，让团队再次进行估算。 大多数情况下，团队现在会将估算值集中在一到两个不同的数值上。 重复讨论过程。 根据具体情况，团队会对两个备选数值中的一个达成一致，或者决定再进行一轮估算。
- 只有当所有团队成员都对最终的估算值完全满意时，估算过程才算完成。 这应该是整个团队的共识，而不仅仅是少数人的意见。 之后，任何团队成员都可以参与任何故事的交付。 这就是为什么每个人都同意故事的复杂性至关重要。
迭代计划承诺
团队现在拥有一系列已经完成估算的、并且通常还会排序的用户故事。 理想情况下，应该为故事分配优先级（除了最终的估算值之外），这样团队就知道下一个迭代中应该处理哪些故事。
接下来是计划会议，团队会选择一些故事用于下一个迭代。 选择哪些故事应该基于以下因素：
✅ 团队会优先考虑高优先级的故事。
✅ 团队在一次迭代中可以完成多少故事点的经验。 这些知识需要通过多次迭代才能积累。 你需要多次迭代来不断调整，才能正确理解这个能力。
✅ 你不应该只考虑总的故事点数和优先级。 另一个需要考虑的因素是团队的技能分布与所选故事的匹配程度。 例如，如果团队只有两名前端开发人员，那么他们可能不会选择全部由前端开发组成的故事。 这会导致这两名开发人员的工作量过大，而团队的其他成员的工作量则较少。 因此，团队的知识结构与迭代内容的有效性密切相关。
速度因子
最重要的是团队的速度（在即将到来的迭代中）。 这个数值与故事点的总数无关。 它代表的是团队在即将到来的迭代中可以完成多少工作。
为了精确地规划迭代内容，我们将以下两个方面结合起来：
- 团队速度——以人天为单位。 团队中一名成员可利用的完整一天工作时间，等同于团队速度中的一个人天。 例如，一个 10 人团队完成为期 2 周的迭代，则团队的容量为 100 人天。
- 通常在一个迭代中完成的故事点数——以故事点衡量。 这个数值来自以往的经验，并且与团队的速度密切相关。
找到最佳平衡点需要时间和实践。
好处和常见错误
令人惊讶的是，在向敏捷团队转型的过程中，有多少团队倾向于让他们的流程变得复杂。 实际上，你需要先“理解”这个过程，然后才能开始以这种模式工作。
不幸的是，第一步也是最困难的一步。 在某些情况下，甚至需要数年时间，尤其是在严格保守的企业环境中，时间似乎停滞不前。
无论如何，以下是当团队“理解”这个过程后会发生的事情：
- 你不再需要计算人力或天数来确定何时可以完成任务。
- 团队将学习如何创建足够详细的故事，以便它们适合迭代周期。 如果故事过于复杂，它会自动分解成多个小故事。
- 团队对每项工作都有一个良好的估算，一旦他们为迭代做好计划，你就会知道什么时候可以交付。
- 这将提高团队的可靠性和可预测性。
- 团队中的每个人都会“处于同一频道”。 他们会看一个故事，然后对它的复杂程度有相似的理解。 也许过一段时间，他们甚至懒得进行估算。 他们可以在脑海中看到数值，并且因为大家都看到了类似的数值，所以即使没有明确的估算，他们也可以在迭代中推进故事的交付。
如果团队仍然无法理解流程或工作方式，通常会发生以下情况：
- 他们仍然坚持使用旧式的人天估算。 他们会将一切都转换为天数或涉及的人数。 故事点或斐波那契数列会直接或间接地表示天数。
- 领导层会根据每个迭代交付的故事点数来比较不同的团队。 这是完全错误的。 一个重要事实没有被理解：每个团队对故事点的评估都不同。 完全没有必要强求两个团队以“相同的方式”估算他们的故事。
- 一个团队的故事点可能意味着画一个圆圈，而对于另一个团队来说，它可能意味着画一个带有平顶、四扇窗户和两扇门的房子。 这完全没问题。
- 有时，团队倾向于将所有内容都估算在两到四个不同的数值之间。 也许是因为他们害怕故事的数值是 123，有人会认为它与天数有关。 但事实上，斐波那契数列有无限多个数字。 我们不必将自己限制在 3、5 或 8 的估算值上。当然，我们可以这样做，但我们绝不需要这样做。
- 估算由资深人员主导，他们会预先设定整个团队的期望。 我们绝不允许任何一个团队成员主导估算。 每个人都有平等的权利表达自己的意见，并且应该被倾听。
总结
从传统的方法转向敏捷估算并不容易，无论是对于团队还是上级领导，都需要一个适应的过程。 为了使这种方法奏效，双方都必须理解这个过程。 如果其中一方不理解，那么过渡期将是一条充满冲突和期望的艰难道路。
但是，一旦一切都调整到位，一些神奇的事情就会开始发生。 团队将能够更好地估算和计划他们的工作，领导层将有更可预测的发布和路线图可以依赖。
接下来，你需要检查可能破坏迭代的不良流程。