Scrum - 你什么时候估计产品待办事项的工作量？

Question

关闭。这个问题是off-topic .它目前不接受答案。












想改进这个问题？ Update the question所以它是on-topic对于堆栈溢出。

9年前关闭。




Improve this question




您的团队在 Scrum 流程的哪个部分对完成给定产品待办事项项目所需的工作量进行了有根据的估计？

例如，假设您有一个产品待办事项项目，上面写着“用户将能够提供他们的电子邮件地址并收到一封电子邮件，其中包含用于重置密码的链接”，计划用于 Sprint 1。

您是否以非常粗略的估计开始 sprint 并对其进行改进？这个“用户故事”什么时候变成程序员可以及时估计的细化行动项目？ (例如:“使用一个文本框和提交按钮构建 Web 表单”= 2 小时)

在 sprint 开始之前，您是否进行了更精细、更准确的估算？在冲刺开始时？或者在设计人员/程序员最终遇到任务的冲刺期间？

Answer 1

通常，估算应该在每个 sprint 开始时分 2 个级别进行:故事级别和任务级别。为了获得最佳结果，产品负责人和团队每次都应该一起做，尽管有时团队在没有产品负责人在场的情况下进行任务级别的估计是可以接受的。

项目估算/路线图构建(故事级别)

在您的第一个 sprint 中，您必须估计至少 80% 的积压项目(我假设产品负责人已经对其进行了优先排序)以构建合理的项目路线图，该路线图将包括按 sprint 分组的故事和初始估计预测的项目长度。

此时，每个故事的估计不是使用小时、天或周，而是使用相对大小的单位(同时包含努力、复杂性和风险)，例如故事点。我们使用斐波那契尺度和Planning Poker对于这个阶段。整个团队积极参与这个过程是很重要的。

之后，团队必须猜测他们能够在第一个 sprint 中完成多少个故事，这将是他们最初估计的速度(点/迭代)。通常，最好不要使用 1 个月的 sprint，而是使用 2 周或 1 周的 sprint 长度来提高估计的准确性。第一次计划通常需要一整天甚至 2 天，具体取决于积压工作的大小、团队规模和冲刺的长度。

在第一轮故事估算之后，产品负责人和团队可能希望重新确定积压工作的优先级以优化成本/ yield 比，因此在达成协议(protocol)之前可能会来回一些。

你应该得到这样的结果:

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)
--------
...

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

利益相关者应该使用燃尽图可以看到此级别的进度，其中 X 轴是冲刺，Y 轴是故事点。

Sprint 估计(任务级别)

每个 sprint 计划阶段的第二部分用于将每个故事分解为任务。在这里，任务本质上应该是高度技术性的，并且使用小时来估计。我们有一个政策，如果任务估计超过 8 小时，那么无论如何都需要将其分解为更详细的任务。结果将是 sprint backlog，任务按故事分组，以及 sprint 燃尽图，其中 X/Y 轴应该分别是 sprint 的天数和小时数。

它应该如下所示:

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
...

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