共计 1439 个字符，预计需要花费 4 分钟才能阅读完成。
Scrum 要求产品在每个 Sprint 中保持可能可交付（例如，经过适当测试 / 集成）的状态，产品所有者 (Product Owner) 声明哪个工作是最优先考虑的，并且工作可以分成薄的垂直切片，通常是以客户为中心的用户故事 (User Stories) 每个都要大于几天。如果我们正在做其他敏捷 (Agile) 的东西，我们不能错过发布日期 (Time Schedule)，因为产品每周或每两周都可以发货。估计错误的唯一缺点是我们会按时发货，同时省略不太重要的功能 – 比瀑布 (waterfall) 或伪敏捷团队 (pseudo-Agile) 今天所遇到的压力更小的工作方式。
在瀑布式方法中 (waterfall approach)，管理人员根据时间确定团队成员的工作负载能力。经理要求选定的开发人员估计他们预期某些任务需要多长时间，然后根据该团队成员的总可用时间分配工作。在瀑布中，测试是在按照特定的职位名称之后完成的，而不是与代码一起编写的。瀑布的缺点是众所周知的：工作总是迟到，总是有质量问题，有些人总是在等别人，而且总是在最后一刻才赶上最后期限。
Scrum 团队采用完全不同的方法。首先，整个 Scrum 团队而不是个人负责这项工作。整个团队负责每个产品 Backlog 项目。整个团队负责测试产品。没有“我的工作”与“你的工作”。所以我们专注于每个产品积压项目的集体努力，而不是每个任务的个人努力。其次，Scrum 团队更喜欢将项目相互比较，或者以相对单位而不是绝对时间单位来估算它们。（最终，这会产生更好的预测。）第三，Scrum 团队将客户可见的需求分解为尽可能小的故事，从而大大降低风险。如果有 7 个人的工作量太大，我们会组建功能团队 (feature team) 消除依赖 (dependency)。
估算过程是什么样的？Scrum 并未规定团队估算其工作的单一方式。根据 Sprint 计划会议的决定，Scrum 定义的唯一估计是团队是否会在此 Sprint 中尝试 PBI。常见的估算方法包括 T 恤尺码（S，M，L 和 XL），2（1,2,4,8）的力量，斐波那契序列 (Fibonacci sequence):1,2,3,5,8 等，或者只是小而不是需要拆分（参见下面的 #NoEstimates）。
在 Product Backlog 改进会议(refinement Meeting) 中，团队与产品负责人坐下来讨论产品 Backlog 顶部的故事。产品负责人通常需要工作量估算来帮助评估 ROI，有效地确定产品 Backlog 中项目的优先级，并预测在给定的发布日期之前哪些项目将准备就绪。因此，产品负责人希望对工作难度进行诚实的评估。
尽管团队中的个性不同，为了收集观点的横截面，所有团队成员通常同时披露他们的估计值是有用的。个人一次出示他们的牌，激发“计划扑克 (Planning Poker)”这个词。个人通常会选择不同的牌。这应该引发对实施方法的讨论，向产品负责人 (Product Owner)澄清要求，并将需求分成较小的故事（其中一些将是较低的优先级）。通常需要几轮来达到单一的工作量估计，这反映了整个团队对故事难度的感觉。改进和澄清比估计本身更重要。根据敏捷宣言，业务人员和开发人员必须在整个项目中每天一起工作。
冲刺增量与潜在可运输产品对比 MVP 与 MMP
为用户故事撰写 SMART 目标和投资
什么是产品 Backlog 中的 DEEP？
如何为 Scrum 项目撰写产品愿景？
如何使用 Scrum Board 进行敏捷开发？
谁在 Scrum 中创建产品 Backlog 项目或用户故事？
