如何为您的项目估算故事点？

在敏捷项目上工作时，团队通过创建故事来计划下一轮迭代的工作。故事定义了一个包含描述和验收标准的单一功能封装活动。

迭代通常持续两到四个星期。团队需要在这段时间内理解他们可以在一个迭代中完成多少内容，以便能够在规定的迭代时间内完成。

在非敏捷项目中，通常会估计工作量。这意味着您需要多少全职员工来完成这项活动？在这种情况下，您总是在创建估计时考虑天数和人员数量。

在敏捷项目中，情况不同了。您不再计算天数或人员来计算最终估计。事实上，我们甚至应该禁止像人天这样的工作量计算。相反，您让团队转换为一个普遍接受的故事值来代表整体估计。

现在，关于这个值到底是什么，这并不重要。确实，故事估计的最常见代表是故事点。这些基本上是从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。我们当然可以（也许我们已经有这个目的创建了那么复杂的故事，在这种情况下这是可以接受的），但我们绝对不需要。
估计由高级人员主导，他们会预先定义整个团队的期望值。我们绝不能允许一个团队成员影响估计。每个人都有平等的权利表达自己的观点，并被倾听。

最后的话

从传统方法转向敏捷估算并不总是容易的，需要团队和领导层都做出调整。为了使其起作用，双方都必须理解这个过程。如果其中一方不理解，过渡期将是一段充满对立期望的困难道路。

但一旦所有的转变发生，一些神奇的事情将开始发生。团队将能够更好地估计和计划他们的工作，领导层将有更可预测的发布和路线图。

接下来，请查看unhealthy processes that can ruin your sprint。

如何为您的项目估算故事点？