Scrum 中就绪的定义

最终用户有时对新功能有想法或概念。概念表示为一个或多个功能项，并由产品所有者添加到产品积压中。团队将共同努力，找出如何将这一概念转化为一个或多个史诗，然后将其细化为更小、更清晰的用户故事，并将其作为真正的产品功能纳入下一个 sprint 实施。

但是，确保在 sprint 之前准备好用户故事可以对团队生产力产生直接而重大的影响。有一个“准备好”的定义意味着故事必须立即准备好实施。团队必须能够确定需要做什么以及完成用户故事所需的工作量

团队会将产品 backlog 顶部的故事拉到 sprint backlog 中。这些故事必须“准备好”。有些公司实际上需要一份详细的清单来确定一个故事是否“准备好”，而不仅仅是“几乎”。

如何创建就绪的定义？

产品负责人可以与团队一起定义一个 称为“就绪的定义”的工件 ，以确保积压工作顶部的项目已准备好进入 sprint，以便开发团队可以自信地提交并完成它们冲刺的结束。

为什么要定义就绪？

就绪的定义是一组让每个人都知道什么时候可以开始的协议，例如，什么时候用户故事准备好进入冲刺，或者什么时候所有必要的条件都适合团队开始冲刺。对就绪的适当定义将大大提高 Scrum 团队成功实现其 sprint 目标的机会。以下是结构合理的 DoR 可以为团队带来的一系列好处：

• 衡量积压项目的“就绪”状态
• 确保产品积压项目已被“恰到好处”考虑
• 帮助团队确定产品负责人或其他团队成员何时不堪重负
• 让团队相互负责
• 在故事“准备好”之前减少团队承诺估算的压力
• 减少开发中的“需求流失”

示例 — 为 Sprint 做好准备的定义

不同的团队会有不同的准备好牙列，有些需要的更少。即，一些团队只是向用户描述价值、优先级和编写演示方法。其他估计和沟通在 sprint 计划会议 等中。以下是为您的团队开发 DOR 时要考虑的示例项目：

• Sprint  Backlog 优先
• Spring Backlog 包含团队承诺的所有缺陷、用户故事和其他工作
• 没有隐藏的工作
• 所有团队成员都计算了他们的 Sprint 容量
• 全职项目 = 每天 X 小时
• 所有用户故事都符合就绪的定义

示例 — 为用户故事做好准备的定义

本节展示了一个用户故事就绪的示例定义，以及一个 Sprint 就绪的示例定义。您可以采用其中一些作为基线或起点：

• 故事对用户的价值是明确的。
• Story的 验收标准 已经明确描述。
• 已识别用户故事依赖项
• 交付团队规模的用户故事
• Scrum 团队接受用户体验工件
• 酌情确定绩效标准
• 确定将接受用户故事的人
• 团队知道如何演示故事。

概括

Scrum 指南中没有描述术语“就绪的定义”。它与嵌入其中的用户故事和验收标准相同。也许您可能认为准备就绪的定义是产品待办列表细化活动的一个组成部分，而不是将准备就绪的定义用作序列和阶段门清单。Backlog细化是一个持续的过程，因此它不限于一个事件，而是被视为一个活动。