真正有用的就绪定义：一份本周即可使用的清单
就绪定义（Definition of Ready，DoR）是关于一个产品待办列表项何时足够清晰、可以纳入Sprint的共同约定。需要先说明：《Scrum指南》并未提及它——Scrum有完成定义，而没有就绪定义。因此DoR是团队选择添加的东西，它必须证明自己的价值。用得好，它就是一次快速的直觉检查，能阻止含糊不清、半成形的需求项被拉进Sprint规划并悄悄拖垮整个Sprint。用得不好，它就会变成由另一个独立的「需求」小组把守的关卡，这恰恰违背了Scrum的初衷。
在2021年年中，许多团队仍分散在各自的居家办公室，供货周期也难以预料，一个被误解的待办项所付出的代价随之上升。你再也无法探过办公桌、用三十秒澄清一处歧义。一份简短而诚实的DoR，帮助分布式团队在Sprint开始之前就把这些问题暴露出来，而不是开始三天后才发现。
实战清单
请把以下内容当作梳理（refinement）过程中的对话引子，而不是一张需要签字的表格。如果某个需求项在大多数条目上都过不了关，它很可能尚未就绪——而补救办法通常是一次五分钟的对话，而非将其驳回。
该需求项描述的是预期结果或用户需求，而不仅仅是某人已经决定好的解决方案。
验收标准已经存在，并且足够具体，使团队对「完成」的样子达成一致。
依赖项是明确的——另一个团队、一家供应商、一项审批、一份数据——并且没有任何一项阻碍工作的启动。
该需求项足够小，能合理地在一个Sprint内完成；如果明显做不到，就先进行拆分。
开发人员对它的理解足以做出预估，哪怕只是粗略的，而无需先开展一个研究项目。
团队所需的一切——测试数据、访问权限、一份设计、一个决策——要么已经具备，要么有明确的获取路径。
如何保持它的轻量
让它属于团队，而非一道检查关卡。 开发人员和产品负责人共同拥有这份DoR。它是用于梳理对话的工具，绝不是由Scrum团队之外的人把守的交接关卡。
把它控制在寥寥数条之内。 团队真正会用的五六条引子，胜过一份没人会读的二十行政策。如果某条检查从未发现任何问题，就把它删掉。
把它当作指引，而非法律来执行。 就绪是一个连续的程度，而非非此即彼。一个团队已经理解、就绪程度达到七成的需求项，完全可以被拉入；DoR的作用是揭示风险，而非禁止判断。
在回顾会议上重新审视它。 如果需求项总是带着未就绪的状态到来，或者DoR把梳理拖得过慢，就调整它。和Scrum中的一切一样，它应当通过检视与调整而不断改进。
最常见的失败，是把「就绪」当成一个非此即彼的印章，而不是一场对话。DoR不是业务分析师交给开发人员的一纸合同；它是整个Scrum团队在梳理过程中所养成的一种习惯，好让待办列表里始终保有几个已经就绪、被充分理解的需求项。一旦DoR开始引发关于某个需求项是否「通过」的争论，团队通常已经滑向了阶段关卡式的思维，丢掉了它的初衷。需要留意的信号很简单：梳理应当让人感觉像团队在达成共识，而不是像一场检查。
就绪定义的意义不在于增添仪式感，而在于确保团队把Sprint规划用在决定如何交付价值上，而不是做到一半才发现大家对工作究竟是什么都从未达成一致。让它保持简短，让它属于团队，并让回顾会议来为它修枝。
如果你的交付团队总是着手开展那些后来才发现只定义了一半的工作，XNM的项目群与项目交付咨询服务 可以帮助你收紧工作从想法到Sprint的流转方式。