Scrum - 何时估算产品待办事项的工作量？

Question

你的团队在Scrum流程的哪个环节做出关于完成特定产品待办事项所需努力的教育估计？

例如，假设你有一个待办事项，内容是“用户将能够提供他们的电子邮件地址并收到一个带有重置密码链接的电子邮件”，安排在Sprint 1中。

你会开始一个非常粗略的估计并加以完善吗？这个“用户故事”何时变成程序员可以按时间估计的详细操作项？（例如：“构建一个文本框和提交按钮的网络表单”= 2小时）

你是在sprint开始之前还是在sprint开始时进行更精确的估计？或者在设计师/程序员最终遇到任务时，在sprint期间进行更精确的估计？

- urig

---

根据相关文章，如果一篇文章“涵盖了一个实际的、可回答的问题，这个问题是软件开发中独特的”，那么这篇文章就被认为是切题的。Scrum产品待办事项估算确实是软件开发中独特的问题。投票重新开放。 - tsilb

Answer 1

通常在每个迭代的开始阶段，需要进行两级估算：故事层面和任务层面。为了达到最佳效果，产品负责人和团队应该一起完成这两级估算，尽管有时候在没有产品负责人的情况下，团队可以仅对任务进行估算。

项目估算/路线图构建（故事层面）

在第一个迭代中，您必须至少估算80％的待办事项（我假设产品负责人已经对其进行了优先排序），以构建一个合理的项目路线图，其中包括按迭代分组的故事和项目长度的初始估计投影。

此时，每个故事的估算都不是用小时、天或周来衡量的，而是使用一个相对大小的单位（同时包含了工作量、复杂度和风险），例如故事点数。我们使用 Fibonacci 序列和 Planning Poker 进行此阶段的估算。整个团队积极参与此过程非常重要。

之后，团队必须猜测他们能够在第一个迭代中完成多少个故事，这将是他们的初始估计速度（点数/迭代）。通常最好不要使用一个月的迭代而是使用两周或一周的迭代长度来提高估算精度。第一次规划通常需要整个团队花费一天甚至两天的时间，具体取决于待办事项的大小、团队的规模和迭代的长度。

在完成第一轮故事估算后，产品负责人与团队可能会重新对待办事项进行优先排序，以优化成本/收益比，因此可能需要反复协商，直到达成一致意见为止。

最终您应该得到类似下面这样的结果：

PROJECT ACME ROADMAP

SPRINT 1 (38 points) <= estimated velocity
--------
Story 1 (21 points)
Story 2 (13 points)
Story 3 (4 points)

SPRINT 2 (40 points)
--------
Story 4 (13 points)
Story 5 (13 points)
Story 6 (8 points)
Story 7 (5 points)

SPRINT 3 (39 points)
--------
...

在接下来的迭代中，这个路线图将被反复修订，在每次迭代开始时，根据团队实际获得的速度调整速度并根据需要重新计算项目长度。有时候，随着团队的发展和需求变化，重新评估故事也是必要的。然而，修订路线图的时间不应超过半天。

在这个层面上的进展应该通过燃尽图对利益相关者可见，其中 X 轴是迭代，Y 轴是故事点数。

决定每个迭代的第二个规划阶段花费在将每个故事拆分成任务上。在这里，任务应该是高度技术性质的，并使用小时进行估算。我们有一个政策，如果任务估计完成需要超过8小时，则需要无论如何将其拆分为更详细的任务。结果将是迭代日程表，按故事分组的任务和迭代燃尽图，其中 X/Y 轴应分别为迭代的天数和小时数。

它应该是这样的：

Sprint 8
--------
Story 17
  Task 1: 8 hours
  Task 2: 6 hours
  Task 3: 2 hours

Story 18
  Task 1: 8 hours
  Task 2: 6 hours

Story 19
  Task 1: 6 hours
  Task 2: 3 hours
...

基本上，这些是你在每个迭代开始时应该进行的两种估算类型，通常第一个迭代需要更多的努力来建立初始项目路线图。

- Dema

---

不要使用时间来估算，我已经这样做很长时间了，结果并不总是积极的。如果你仍然在第二次估算中使用努力，那么每个冲刺的速度将给出所需的时间。如果你使用时间来估算，几乎总是会失败。 - iberbeu

Answer 2

在Sprint规划之前，应该先进行大致估算，以便团队在此阶段选择特定的项目。通常，在Sprint期间的上下文切换或空闲时间里，我们会对“故事点”中的新条目进行大致估算，以便产品负责人可以在下一个Sprint计划之前适当地对它们进行优先级排序。

我们的Sprint计划通常限时2小时，位于新Sprint的开始阶段。这是我们与产品负责人会面并从待办事项中挑选项目的时间，其中大多数已经进行了大概估算和正确的优先级排序。如果有遗漏的估算，我们会立即进行补充，然后在此时间窗口内对故事进行“精细化”任务分配（通常是相当紧张的工作），利用公司其余部门了解情况、产品负责人和利益相关者可用于解决未考虑到的细节问题这一优势。

当然，有时实施任务序列会与计划中的任务分配不同，那么就需要进行调整，并且Burn down图表可能需要重新调整。

“任务燃尽”中的Burndown
我们简单地使用任务数量作为我们的Burn down度量标准。通常您会使用实际小时数或理论小时数之类的东西，但这对我们来说已经足够好了，并且似乎有足够的需要进行一些澄清。

我们不会在这些任务上估计时间，所有事情只关心故事点估算（即大致估算）和理想工作日(ideal man days)。如何将该故事拆分为任务是团队分配和总体进度指示器的更多事情，而不是为我们进行准确的小时估算。

最终，我们处理了x个故事点，并从中获取与团队当次Sprint可用工作日实际相符合的焦点因子。

最终，基于“故事点”中的粗略估算（即我们可以在一个Sprint周期内完成多少“故事点”），我们选择故事。我们倾向于在粗略估算方面变得更加专业 - 我认为这很重要，因为产品负责人主要基于这一点来对待办事项进行优先级排序，而永远不会基于任务估算 - 因为那是团队内部的事情。

由于任务本身没有明确的时间估计，因此重点放在故事点的粗略估计上。如果这些任务一起花费的时间比估计的故事点 * 重点因素更多，那么我们只是在粗略估计时出了错误或者应该在冲刺计划期间进行修正，因为此时大多数信息应该已经可用或者已经整理好了。

- Oskar Duveborn

---

嗨，奥斯卡，所以你不是烧掉开发时间，而是烧掉完成的任务数量？那么什么是“任务”，这些是你在冲刺计划中制定的“细粒度”任务吗？ - Simon Keep

是的，我们燃尽的任务是在冲刺计划期间产生的细粒度任务。这是为了简化事情而不是燃尽小时或其他什么东西，结果还不错（对我们来说）。 - Oskar Duveborn

Answer 3

目前，我们在冲刺开始之前会制定详细的任务分解和估算。这是由于以下两个原因：

1）我们的业务需要这些估算来帮助他们确定优先级。

2）开发团队承受着按照估算交付并且不偏离自然燃尽的压力。

在我看来，这种方法是错误的，因为它剥夺了敏捷性。我认为流程应该更像这样...

1）业务人员应该使用规划会议上产生的斐波那契数列来帮助他们确定优先级。或者至少只期望从开发团队得到一种"粗略估计"。

2）燃尽图应该被视为项目进展的指南，以指示是否需要添加更多PBI，或降低优先级，而不是作为一个确定完成内容的严格 "目标"。

这样工作将允许我们花费更少的时间在规划和设计上。我们仍然会在冲刺开始时制定高水平的估算，并在冲刺进行时进行修正。

在与我的业务进行争辩之前，我很想听听大家的意见。

- Si Keep

---

大部分同意。我认为像你所说的，在冲刺之前给PO提供粗略的估计很重要，而不是详细的任务分解，但这意味着需要在冲刺计划几天或几周之前帮助他们进行优先排序。你想要使用燃尽图的方式也似乎是正确的。 - Oskar Duveborn

在过去的几个月中，我们一直在更加努力地工作，并且这种方式通常适用于每个人。我们的计划通常只需要一两天的时间，而且我们因为自然下降而落后时也会少些抱怨。 - Simon Keep

我有一个关于1和2的问题。把估计值等同于承诺是错误的吗？如果是，那么估计值有什么价值？我认为当我们把估计值等同于承诺时，开发团队会承受更大的压力，变得不够敏捷。这也会降低代码质量。我非常希望听到一些评论。 - daehaai