scrum - Scrum-您何时估计产品积压项目的工作量？

Closed. This question is off-topic。它当前不接受答案。












想改善这个问题吗？ Update the question，所以它是用于堆栈溢出的on-topic。

已关闭8年。



Improve this question




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

例如，假设您有一个产品待办事项列表，其中列出了计划在Sprint 1上进行的“用户将能够提供其电子邮件地址并接收带有用于重置其密码的链接的电子邮件”。

您是否以非常粗略的估算开始冲刺并进行优化？这个“用户故事”何时会变成程序员可以及时估计的细粒度操作项？ (例如:“使用一个文本框构建Web表单并提交按钮” = 2小时)

在冲刺开始之前，您是否进行了更好，更准确的估算？冲刺开始时？还是在冲刺期间，只要设计者/程序员最终碰上了任务？

最佳答案

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

项目估算/路线图构建(楼层)

在您的第一个冲刺中，您必须估计至少80％的积压项目(我假设产品所有者已经对其进行了优先排序)才能构建合理的项目路线图，该路线图包括按冲刺分组的故事和初步估计的投影项目长度的

目前，每个故事的估算不是使用小时，天或周，而是使用相对大小单位(包括同时涉及工作量，复杂性和风险)，例如故事点。在此阶段，我们使用Fibonnaci量表和Planning Poker。整个团队积极参与此过程非常重要。

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

经过第一轮故事评估后，产品负责人和团队可能希望重新安排积压的优先级，以优化成本/ 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轴是故事点。

冲刺估计(任务级别)

每个冲刺计划阶段的第二部分是将每个故事分解为任务。在这里，任务本质上应该是高度技术性的，并且需要花费数小时。我们有一项政策，如果预计任务时间超过8小时，则无论如何都需要将其分解为更详细的任务。结果将是sprint积压，按故事将任务分组，以及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
...

因此，基本上，这是您在每次冲刺开始时应进行的两种估算类型，通常，第一个冲刺需要花费更多的精力来构建初始项目路线图。

关于scrum - Scrum-您何时估计产品积压项目的工作量？ ，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/502731/