您的团队在Scrum流程的哪个部分对完成给定产品积压项目所需的工作量进行了有根据的估算？
例如，假设您有一个产品待办事项，其中显示“用户将能够提供他们的电子邮件地址并收到一封电子邮件，其中包含重置密码的链接”，计划用于Sprint 1.
您是否以非常粗略的估计开始冲刺并进行优化？这个“用户故事”什么时候变成了程序员可以及时估计的粒状动作项？ （例如：“使用一个文本框和提交按钮构建Web表单”= 2小时）
在冲刺开始之前，您是否进行了更精细，更准确的估算？冲刺开始时？或者在sprint期间，只要设计师/程序员最终碰到任务？
答案 0 :(得分：26)
通常，估算应在每个冲刺开始时以2个级别进行：故事级别和任务级别。为了获得最佳结果，产品所有者和团队应该每次都一起做，尽管有时在没有产品所有者在场的情况下，团队在任务级别进行估算是可以接受的。
在你的第一个sprint上，你必须估计至少80％的积压项目（我假设产品负责人已经优先考虑）来建立一个合理的项目路线图，其中包括以短跑方式分组的故事和项目长度的初步估计预测。
此时，每个故事的估计是使用而不是小时，天或周来完成的，而是大小的相对单位（包括所有同时的努力，复杂性和风险），例如故事点。我们在此阶段使用Fibonnaci量表和Planning Poker。整个团队积极参与这一过程非常重要。
之后，团队必须猜测他们能够在第一个冲刺中完成多少个故事，这将是他们的初始估计速度（点/迭代）。通常，最好不要使用1个月的冲刺，而是使用2周或1周的冲刺长度来提高估计准确性。第一次计划通常需要一整天甚至两天，具体取决于积压大小，团队规模和短跑的长度。
在第一轮故事评估之后，产品所有者和团队可能希望重新确定积压的优先级，以优化成本/效益比，因此可能会有一些来回，直到达成协议。
你应该得到这样的东西：
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轴是故事点。
每个sprint的规划阶段的第二部分用于将每个故事分解为任务。在这里，任务应该是高度技术性的并且使用小时来估计。我们的政策是，如果任务估计超过8小时，那么无论如何都需要将其分解为更详细的任务。结果将是sprint积压，按故事分组的任务和sprint燃尽图表，其中X / Y轴应分别为sprint和hours的天数。
它应该是这样的：
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需要更多的努力来构建初始项目路线图。
答案 1 :(得分：9)
粗略估计应在sprint计划之前完成，其中该团队应该选择此特定项目。通常我们会在上下文切换期间检查产品待办事项或在冲刺期间停机，以便对“故事点”中的新项目进行粗略估计，因此产品所有者可以在下一个sprint计划之前对其进行适当的优先排序。
我们的冲刺计划通常在新冲刺开始时按时间限制为2小时。这是当我们与产品所有者会面并从积压中挑选物品时，其中大部分都是粗略估计并正确划分优先顺序。错误的估计是在现场完成的，然后我们在这个时间窗口（这通常是非常紧张的工作）中对故事进行“细粒度”任务，充分利用公司其他人知道这一点和PO和利益相关者可以解决下落不明的细节。
当然，有时执行任务序列会与计划任务不同，然后必须进行调整，并且可能需要重新调整燃尽图。
任务中的Burndown
我们只是为我们的燃尽测量使用多个任务。通常你会做一些像实际时间或理想时间这样的事情，但这对我们来说已经足够了，而且显然很有趣，需要一些澄清。
我们不估计这些任务的时间，所有重要的是故事的故事点估计（粗略估计），我们把它放在理想的人日。
这个故事如何分成任务更多的是团队分配和一般进度指标，而不是为我们做出准确的小时估算。
最后，我们处理了x个故事点，并从与sprint团队中实际可用工作日相关的关注因素得出。
最后，故事点的粗略估计是我们的故事选择的基础（即，我们可以在冲刺中做多少sp）。我们倾向于在粗略估计中变得更好 - 我认为这很重要，因为产品所有者主要基于此优先考虑积压中的项目，并且从不基于任务估算 - 因为那是团队内部。
由于任务没有明确的时间估计，重点是故事点的粗略估计。如果任务共同花费的时间比估计的故事点*焦点因素更多，我们只是粗略估计错误，或者应该在sprint规划期间纠正它，因为大多数信息应该可用或整理出来。
答案 2 :(得分：4)
目前，我们会在sprint开始之前生成详细的任务细分和估算。这有两个原因：
1）我们的企业希望估算能够帮助他们确定优先级。
2）开发团队面临着达到预期并且不会偏离自然灾害的压力。
在我看来，这是错误的方法，因为它消除了敏捷的能力。我认为这个过程应该更像......
1）企业应使用计划会议期间产生的斐波那契数字来帮助他们确定优先级。或者至少只期待开发团队的“空中手指”估计。
2）燃烧图表应被视为项目进展情况的指南，以指示是否需要增加更多PBI或降低优先级更低的PBI，而不是作为完成目标的公司“目标”。 / p>
以这种方式工作将使我们在规划和设计上花费更少的时间。我们仍然会在冲刺开始时产生一个高水平的估计，这可以在冲刺继续进行时进行改进。
在与我的公司展开激烈竞争之前，我将有兴趣对此发表评论。