共计 2168 个字符，预计需要花费 6 分钟才能阅读完成。
任务计划和评估对于按照优先产品 Backlog 中指定的要求迭代开发产品至关重要。Scrum 团队在任务评估会议中估算完成任务列表中每项任务所需的工作量。此过程的结果是 Effort Estimated Task List。Scrum 团队使用 Task 列表，这是一个包含团队为当前 Sprint 提交的所有任务的综合列表，用于开发 Effort Estimated Task List。任务列表必须包括任何测试和集成工作，以便 Sprint 的产品增量可以成功地集成到之前 Sprint 的可交付成果中。尽管任务通常基于活动，但任务被分解的粒度级别由 Scrum 团队决定。在任务评估会议期间，Scrum 团队使用任务列表来估计完成任务或任务集所需的工作量，并估计在给定 Sprint 中执行任务所需的人员工作和其他资源。该技术的一个主要优点是，它使团队能够对用户故事和需求拥有共同的视角，以便他们可以可靠地估计所需的工作量。任务估算会议中开发的信息包含在“工作量估计任务列表”中，用于确定 Sprint 的速度。在本次研讨会中，Scrum 团队可以使用各种技术，如分解，专家判断，类比估计和参数估计。任务评估会议也可以与任务计划会议相结合。
为了保持相对估计大小并最小化重新估计的需要，团队使用估计标准。估计标准可以用多种方式表达，两个常见的例子是故事点和理想时间。
例如，理想时间通常描述 Scrum 团队成员专门开发项目可交付成果的小时数，而不包括花在项目之外的其他活动或工作上的任何时间。通过评估标准，Scrum 团队可以更轻松地估算工作量，并使他们能够在必要时评估和解决效率低下问题。
任务估计的输出是 Effort Estimated Task List。它是与 Sprint 中承诺的用户故事相关联的任务列表。通常，估算的准确性因团队技能而异。估计的努力以团队商定的估算标准表示。Scrum 团队在 Sprint 计划会议期间使用此 Effort Estimated Task List 创建 Sprint Backlog 和 Sprint Burndown Chart。
团队集体估算
在 Scrum 开发期间，团队分担责任并共同致力于每个 Sprint 的工作，因此敏捷团队的估计工作量使用了集体估算方法。集体估算通常使用规划扑克作为工具，团队通过玩估计游戏进行集体估算。规划扑克被认为是在敏捷中进行工作负荷估算的最有效和最有趣的技术。它由一组类似于斐波纳契数的数字组成，包括：0,0.5,1,2,3,5,8,20,40，？，∞，扑克牌每组有 4 组这样的斐波那契数字用于服务供 4 人使用。
群体与个体估计的准确性
根据一些关于软件项目实验中个人和小组之间努力估计准确性的研究。来自同一公司的 20 名软件专业人员分别估算了实施相同软件开发项目所需的工作量。参与者有不同的背景和角色，软件项目以前已经实施过。之后，他们组成了五个小组。每个小组通过讨论和结合他们之间的知识来商定一项估计。
结果 – 基于小组讨论的估算比个人估算更准确。
进行计划扑克的步骤
每个团队成员获得一组卡片，包括 0,0.5,1,2,3,5,8,13,20,40，？，∞，共 12 张牌。
该产品所有者要么读描述要素的团队。
团队成员讨论该功能，并在需要时询问产品所有者问题。
当成员完成讨论后，他们每个成员选择一张扑克牌来代表估计。然后同时显示卡片。
如果团队评估不同的估计。我们同意吗？我们有差异吗？有什么我没考虑过的吗？那些选择最高或最低价值的人应该在每个成员选择另一张扑克牌之前与小组分享他们的推理。
讨论结束后，您可以估算另一轮，团队需要达成协议。
返回第二步并开始估计下一个条目。
估计大小，而不是估计时间段，使用相对估计而不是绝对估计
估计只不过是一个受过良好教育的猜测。我们利用手头的所有知识和经验来猜测它将花费的时间。因此，不是单独查看每个新工作项，为什么不将它与以前完成的工作项进行比较？人类更容易与类似物品相关而不是猜测事物的实际大小。
例如，它是否更接近这个非常小的东西？或者它更像这个正常大小的项目？还是像我们上个月完成的那项工作一样真的很大？做相对估计不仅会减少估算工作所花费的时间，还会大大提高估算的准确性。
我们的大脑无法进行绝对估计; 我们总是把我们需要估计的新事物与我们已经知道的事物相关联。
故事点估计
估计速度 – 记录和平均每个 Sprint 的团队速度
该团队的速度是多少故事点数的 Scrum 团队在一个 Sprint 实际完成。团队速度告诉你团队的速度有多快。一个新估计的项目或团队（过去没有参考速度记录），我们可以做 1 - 2 个 Sprint 来测量速度作为初始速度。在 Sprint 实施过程中，我们需要记录每个 Sprint 的速度，以便将来的计划。
估计用户故事速度
我们估计产品 Backlog 的故事点总数，然后我们知道每个 Sprint 的平均速度，然后我们可以计算出我们需要完成多少 Sprint，因此预计 Sprint 将是项目所需的。如下图所示。
Scrum 项目持续时间估算
其他 Scrum 实用技术
什么是 Scrum 中的 Sprint 目标？
什么是 Scrum 中的 Burndown 图表？
什么是角色 – 功能 – 原因模板？
Sprint 增量与潜在可运输产品对比 MVP 对 MMP
为用户故事撰写 SMART 目标和投资
谁在 Scrum 中创建产品 Backlog 项目或用户故事？
什么是敏捷估算？
什么是敏捷中的故事点？如何估算用户故事？
