大多数团队都有“完成”的定义。拥有“就绪”定义的人要少得多。结果是：故事以截然不同的准备状态进入冲刺，冲刺计划变成分类，冲刺中期的惊喜吞噬了目标。
就绪定义 (DoR) 是完成定义的上游同级。完成定义（DoD）表示工作何时可以结束冲刺。 DoR 说工作什么时候可以进入。这是大多数团队都会跳过的最便宜的敏捷基础设施。
这是实用版本。 DoR 实际上做了什么。捕捉最可预防的意外的五个准入标准。过度设计的 DoR 的陷阱。以及如何引入它而不将精致变成看门仪式。
DoR 的用途是什么
就绪的定义回答了一个问题： 在冲刺计划中遵守这个故事安全吗？
当故事半生不熟地进入冲刺时，会发生三件事：
- 估计是错误的。 工程师在冲刺中期看到了他们在计划时看不到的隐藏复杂性。这些观点是对不同故事的猜测。
- 目标被淡化。 冲刺中期的发现将精力从目标一致的工作上转移开。伸展变成“做了一些”。
- 细化发生在冲刺期间。 工程师追寻验收标准，寻找设计，向利益相关者询问缺失的决策；应该发生的工作 之前 承诺。
DoR 是结构修复。不符合它的故事不会进入冲刺。时期。
最令人惊讶的五个准入标准
大多数 DoR 都会列出一个包含 12 项的清单，但没有人真正检查。这是抓住重要工单的精益版本：
1.这个故事有一个明确的“为什么”
用户价值要么从标题中显而易见，要么故事说明了这一点。没有上下文的“添加缓存层”无法通过此测试。 “将仪表板 p95 上的 API 延迟从 800 毫秒减少到 200 毫秒”通过。
测试：非故事作者能否用一句话解释为什么它很重要？
2. 验收标准存在且可测试
至少是最小可行集；三颗子弹；并且每一项都可以商定为满足或不满足。 （参见 验收标准格式 获取完整指南。）
测试：阅读标准。这些陈述是任何人都可以做的吗？ 检查，或者是他们的愿望？
3.故事很小，可以估计
如果团队在几轮计划扑克中无法就观点达成一致，那么故事还没有准备好。它要么太大（将其分开；参见 故事分割器），或太不清楚（进一步细化，或转换为尖峰）。
测试：团队能否给出一个自信的估计，而不是“耸耸肩，也许是 8”？
4. 外部依赖被识别并畅通
如果工作取决于另一个团队的设计、API 密钥、数据源或利益相关者的决定；这些需要在承诺之前解决（或明确接受为风险）。
测试：列出依赖项。对于每个人来说，答案是“我们拥有它”还是“我们选择承担风险”？
5.有人拥有它
无论是一名工程师还是一组明确的工程师都可以从头到尾地讲述这个故事。 “当我们开始时我们会弄清楚谁”是行不通的；这就是渗透到冲刺中的发现过程。
测试：在第一天的站立会议中，谁会说“我正在做这个”？
就是这样。五次测试。大多数通过这些的故事不会让团队在冲刺中期感到惊讶。大多数失败的故事都是失败的。
DoR 是什么 不
DoR 是设计最过度的敏捷制品。常见的臃肿拒绝：
- “所有的技术设计都必须完成。” 不会。大多数故事的设计都是在创作过程中进行的。如果一个故事需要前期设计，那么它就是一个尖峰，而这个尖峰就是前身。
- “所有用户体验模型都得到了所有利益相关者的批准。” 不。用户体验需要足够的定义才能开始，而不是完全签核。签字阻止运输； “足以开始”可以实现这一点。
- “由整个团队在规划扑克会议中进行估算。” 不会。有些团队会这样做；有些团队会这样做。有些团队有较小的改进人员估计，然后在规划时进行验证。不要烘烤你的 过程 进入您的 DoR。
- “通过父子映射链接到 JIRA 史诗。” 不，这是工具偏好。 DoR 是关于故事是否准备好，而不是工单是否已填写 14 个字段。
- “有一个完全分解的任务列表。” 不。应该允许团队在工作时发现任务。强制分解会鼓励假分解（工程师编写他们会忽略的任务）。
模式：DoR 应该测试 结果 （这可以安全地承诺吗？），而不是 输出 （这个文物已经生产出来了吗？）。每件需要人工制品的物品都是一种税。每一个提出真正问题的项目都是信号。
DoR 在工作流程中的位置
流程：
- 故事进入待办列表（松散、半生不熟，没关系）。
- 细化 使其走向“就绪”状态。细化是满足 DoR 标准的会议。
- 故事被标记为“就绪”。
- 冲刺计划 从 Ready 故事中精选。尚未准备好的故事不符合资格。
- 冲刺跑。 DoD 适用于离开。
结构规则：精益求精。计划从现成的东西中挑选。如果你的团队从“看起来有趣的事情”开始计划，DoR 就没有什么可咬的。
（与 待办事项细化操作手册 会议形式。）
如何引入 DoR，而不使细化成为看门仪式
团队采用 DoR 时的两种失败模式：
失败模式1：DoR 变成纯粹的开销。 每个故事都会有 20 分钟的辩论。首相越来越不满。工程师不假思索地机械地检查项目。精炼时间变长；其他一切都没有改善。
失败模式2：DoR被忽略。 团队同意 DoR。故事进入冲刺而不满足它。没有人强制执行。 DoR 具有装饰性。
两者的修复： 团队可以有意识地覆盖 DoR，但覆盖会被记录。
具体来说：
- 不符合 DoR 的故事可以提交 如果团队明确接受风险 并写下缺少的内容。
- 在回顾中，团队会审查优先事项：缺失的部分是否被咬住？如果是的话，DoR 下次应该抓什么？如果不是，该标准是否必要？
这将 DoR 从门转变为学习工具。团队要务实；团队也不能假装同样的惊喜总是偶然发生。
DoR何时应该更紧或更松
标准 5 项 DoR 适合大多数团队。偏差：
在以下情况下更严格的 DoR（添加标准）：
- 团队事故率高；惊喜令人心痛
- 分布式/异步；冲刺中期修复的机会更少
- 严格合规领域（医疗保健、金融、监管）：变革成本高昂
- 涉及多个专业（后端+前端+ML）：协调成本是真实的
添加诸如“附加设计审查”、“API 合同记录”、“现有测试计划”之类的内容。
在以下情况下更宽松的 DoR（丢弃标准）：
- 团队很小，迭代非常快； DoR 开销超过收益
- 高发现工作（早期产品、研发）：假装故事已经准备好是虚构的
- 具有强烈个人所有权的团队；工程师在工作中填补空白
删除诸如：显式所有者、完整标准、依赖性检查等内容。保持最低限度：明确的“原因”和粗略的尺寸感。
不同冲刺类型的 DoR
并非每个冲刺都进行相同类型的工作。调整：
功能开发冲刺：完整的 5 项 DoR。重点是致力于范围明确的功能工作。
错误修复冲刺: 宽松一些。许多错误本质上是探索性的。 bug 的 DoR =“一致地再现或有一个明确的再现步骤，我们将首先验证”。
发现冲刺: 宽松多了。大多数故事都是尖峰。 DoR =“有时间限制且有明确的问题需要回答”。
科技债务冲刺：对结果更严格，对用户“原因”更宽松。 DoR =“后状态是可观察的”+“团队同意现在值得这样做”。
不要对所有冲刺类型应用相同的清单。重点是冲刺结果与承诺相匹配，并且保护这一点的问题因冲刺类型而异。
没有 DoR 会出现什么问题
需要注意的三种模式，缺失 DoR 的所有症状：
“我们是在开始之后才发现这一点的”
这个故事没有明确的“原因”或接受标准。在冲刺中期，团队意识到工作量更大或有所不同。到那时，冲刺目标就落空了。
修复：DoR 的标准 1 和 2。
“我们正在等待营销/设计/法律/另一个团队”
在承诺之前，依赖性未被识别或未被解决。现在工程师被阻止了，冲刺对他们来说没有有用的工作了，积分被重新洗牌。
修复：DoR 的标准 4。
“它变成了史诗”
故事总是太大；该团队通过平均猜测得出 5 分。在冲刺中期，很明显它是 13+。要么它不交付，要么放弃其他工作来使其交付。
修复：DoR 的标准 3（超大时使用故事分割器）。
如果您在任何一次回顾中看到其中两个，那么您的团队就缺少 DoR。解决办法是结构性的，而不是动机性的。
分布式/异步团队的 DoR
当团队异步时，DoR 更重要。理由：
- 在不花一天时间等待时区重叠的情况下澄清冲刺中期的机会更少
- 无法通过拍别人的肩膀来修复隐藏的上下文
- “我们边走边解决”变成“我们因为无法同步而损失了两天”
对于异步/分布式团队，至少添加：“故事已写下所有上下文；无需口头传统即可理解它”。这抓住了请求者头脑中已有上下文但从未将其写下来的陷阱。
底线
完成的定义表示工作何时可以离开冲刺。就绪的定义是指工作何时可以进入。大多数球队都有第一名；大多数球队需要第二个。
五个标准；明确原因、可测试的验收标准、可估计的规模、已确定的依赖性、可分配的所有者；捕捉那些破坏大多数冲刺的惊喜。不要让清单变得臃肿。不要假装这是一扇坚硬的门。有意识地使用覆盖并在回顾时回顾它们。
认真采用 DoR 的团队通常会发现他们在两个周期内将冲刺混乱减少了三分之一，而代价是召开了一次稍微严格的细化会议。
这就是交易。拿走吧。