待办事项细化：30 分钟的操作手册（以及其中不应该发生的事情）

“待办事项整理”或“待办事项细化”是大多数团队半跳过的会议；没有 Scrum 导游仪式，目前很难感受到它的价值，而经营不佳的工单感觉就像是 90 分钟争论工单说明。这篇文章是操作手册：精炼的实际用途、有效的 30 分钟版本、破坏精炼的两种反模式，以及精炼会议中不应该发生的事情。

待办事项细化的实际用途是什么

三个具体产出。如果你的改进没有产生这些效果，那么你的会议就是错误的。

1. 山顶附近的工单 待办列表 描述未来您（或队友）可能会感冒。
的 验收标准 是在工单上的。作品的形状在工单上。 “为什么”在工单中；即使只是一句话。如果没有这个，冲刺计划就变成了“这张票又意味着什么？”

2. 工单大致尺寸。
并不是每张票都有 故事点 还没有。但是你可能会进入接下来的 1-2 个冲刺的工单应该有一个数字，甚至是一个大概的数字。如果没有规模，冲刺计划就会变成规模调整会议，这使得计划会议需要 90 分钟。的 故事点估算器 当团队意见不一致时会有所帮助。

3.太大的故事会被分裂。
一个经过精炼发现的 13+ 故事是 很多 拆分比计划中发现的同一个故事更便宜。在计划中，你必须在时间压力下将其分开，并让整个团队等待。细化的话，大家可以思考一下。的 故事分割器 给你八种模式可供选择。

就是这样。三个输出。描述质量、尺寸、分裂。

30分钟版本

对于一个由 4-7 名工程师组成的团队进行为期 2 周的冲刺，这是时间表。冲刺中期，每周节奏（即，在计划的休息周，运行一次；在计划周，跳过）。

00:00 - 00:03  | Quick context; what's in the next sprint shape?
00:03 - 00:18  | Walk top 5-8 backlog items
                  • Lead reads ticket title + acceptance criteria
                  • Anyone on team flags missing detail or risk
                  • Estimate (or "needs spike")
                  • Move to next
00:18 - 00:25  | Splits and spikes
                  • For each story flagged 13+ or "unclear"
                  • Either propose a split now or create a 1-pt spike
00:25 - 00:30  | Backlog tidy
                  • Bump priority of recently-blocked items
                  • Mark dead tickets as cancelled (don't quietly carry them)

总计：30 分钟。每周重复。一个人负责（通常是领导）。随着时间的推移旋转。

最重要的规则：细化不是实现设计

这是大多数团队打破的规则，也是大多数改进持续 90 分钟的原因。

细化来说，每张票的正确问题是： “我们明白‘完成’是什么样子吗？这个值足够小吗？”

错误的问题是： “我们将如何从技术上构建这个？”

“如何”对话属于规划后的实施，此时挑选票的工程师独自处理代码库。一个 6 人团队围绕“我们应该使用轮询方法还是推送 Webhook”争论 20 分钟，每个冲刺都会浪费 2 小时的工程时间，而这个决定应该由收到工单的人做出。

廉价的启发式：如果对话转向特定的类名称、库选择或“我认为我们应该使用 X 模式”，请停止并标记它以进行后续操作。细化不是地方。继续前行。

反模式 1：无声待办列表转储

症状：领导者整个星期都在添加工单。细化是团队第一次见到他们。工程师们盯着不熟悉的工单，而领导者则阅读每一张工单，说“有什么问题吗？”，而团队在没有背景的情况下说“没有”。

结果：工单未经审查就被盖上橡皮图章。两周后的计划中，有一半的计划被证明是含糊不清、规模过大或错误的。

修复：在整个冲刺期间，工单都会添加到待办列表工作中，团队负责人在创建工单时会编写一行描述和验收标准。每个人都可以访问待办事项并可以在一周内进行扫描。细化是一个 检查，不是首次审查。

如果您的团队确实没有时间了解异步待办列表工作，那么您就不存在细化问题；您有待办列表的所有权问题。领导者负责团队的思考，而不是分发它。

反模式 2：开放式讨论

症状：一张票引发了 20 分钟的讨论。三个人的看法各有不同。协调员让它继续运行，因为“保持一致很重要”。

结果：精炼结束，团队变得疲劳，接下来的 4 张罚单就被盖了橡皮图章，因为没有人有精力。

修正：每张票 5 分钟硬上限。如果一张工单需要超过 5 分钟的讨论来细化，那么它就不是细化的；它已被阻止，正确答案是以下之一：

• “这需要一个 尖峰。创建 1 分票：‘调查 X，提出方法。’”
• “这太大了，分了，下次精炼我带着分票回来。”
• “这需要客户/产品经理澄清。给他们贴上标签，我们会重新审视。”

这些都是 合法的细化输出。 “我们为此争论了 20 分钟”不是。

精炼过程中绝对不应该发生什么

一个简短的清单，是通过艰难的方式学到的：

1. 现场写票。 如果工单不清楚，需要在会议中重写，会议就会停止；领导者取得所有权；下周再访。
2. 估算团队中没有人会处理的工单。 如果是前端票并且只有一名工程师做前端，就不要让 5 个人来估算。私聊前端工程师；捕获;继续前行。
3. 重新诉讼团队已经估计的工单。 一旦某个号码开启，它就会保持不变，除非发生重大变化（范围、依赖性、要求）。
4. 添加工单 期间 细化。 新票进入待办列表。它们将在下周完善，而不是现在。
5. 谈论 5 个以上 sprint 之外的工单。 细化接下来 2 个冲刺的价值。任何进一步的努力都是浪费精力，因为优先事项会发生变化。

看板团队怎么样？

Kanban 团队没有冲刺仪式，但存在同样的需求：需要准备好拉动接近待办列表顶部的工单。格式变成每周 15 分钟的“准备检查”；相同的输出（描述、大小、分割）但体积较小，因为您只查看附近的内容 在制品 边界。

如果您是 scrumban，请运行 30 分钟的 scrum 格式。

拥有产品负责人的团队怎么样？

PO 编写工单描述并决定优先级。工程团队估计并标记分裂。会议是PO和工程师在同一个房间开的。 PO 没有估计。

一种常见的失败模式：PO 编写了 3 行描述，团队对其进行了估计，后来才意识到该描述缺少关键上下文。解决方法是团队询问“对于用户来说完成的是什么样的？”对于每张票，不仅仅是“描述完整吗？”；描述可能看起来很完整，但仍然达不到用户的实际期望。

做得不好的代价

完全跳过细化的团队每个冲刺会损失大约 2 个小时的时间来思考“这意味着什么？”计划期间的对话，加上冲刺中期发现工作量比预计的要大。对于一个 6 人团队来说，每个 冲刺 浪费的工程时间约为 3,000 英镑。

按照典型的英国工程成本计算，每周 30 分钟的改进会让团队每个冲刺的成本约为 1,000 英镑。数学很简单。

SprintFlint 中的内容是什么样的

SprintFlint 显示待办事项列表，其中包含故事点、调整徽章和自动应用于接下来 2 个冲刺中任何内容的“需求细化”标签，而无需描述或估计。细化会议变成“看这个过滤器，沿着清单走”；没有票落空。

对于不会切换工具的团队，便宜的版本：Linear/Jira 过滤器 priority > 0 AND points = empty AND sprint = next-two，每周运行一次。

长话短说

• 细化产生三件事：工单描述、大小、分割。没有别的了。
• 每周 30 分钟，一名辅导员。跳过计划周。
• 每张票的正确问题是：“我们知道‘完成’是什么样的吗？”不是“我们将如何建造它？”
• 每张票有 5 分钟硬上限。更大的对话会产生峰值、分裂或澄清请求。
• 不要细化团队中没有人会处理的工单。不要在会议中写票。不要谈论 5 冲刺工作。
• 跳过细化的团队会因计划混乱而在每个冲刺中损失约 2 小时。 30 分钟的会议避免了这种情况的发生。