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