“冲刺待办事项”和“产品待办事项”听起来像是同一件事。但事实并非如此，混淆它们是敏捷团队规划混乱的最常见来源之一。
以下是对每个概念的诚实解读，为什么差异很重要，团队模糊它们的四种方式以及模糊它们时会发生什么，以及解决 90% 混乱的简单结构修复。
实际定义（无行话）
产品待办列表: 每一个想法 可能 最终完成。开放式。归总理所有。通常比团队所能交付的规模还要大。
冲刺待办事项：团队拥有的具体物品清单 承诺在未来 1-4 周内完成。封闭范围。在冲刺期间由团队拥有。
关系：冲刺待办事项是从冲刺计划中的产品待办事项中提取的一小部分。一旦冲刺开始，团队的冲刺待办列表工作就会被冻结。产品待办事项仍在不断发展。
就是这样。其他一切都源于这两个想法。
团队模糊两者的四种方式
1. 将 sprint backlog 视为愿望清单
症状：在冲刺计划中，团队为 30 点的冲刺选择了 50 个工作点，“以防万一我们有额外的时间”。
为什么会出错：具有延伸目标的冲刺待办列表工作并不是冲刺待办列表工作；这是一个充满希望的愿望清单。团队不能说“我们承诺了这一点”，因为承诺从一开始就很模糊。冲刺目标变得毫无意义。速率变得毫无意义。利益相关者知道“承诺”并不意味着承诺。
解决办法：冲刺待办事项就是您所要做的 将会完成，按实际容量确定。如果您在冲刺结束时有额外的产能，请从产品待办列表中提取新的工单。不要预先承诺。
2. 将产品待办事项视为等待中的冲刺计划
症状：产品待办事项列表的顶部是“此冲刺的计划工作”，然后是“下一个冲刺的计划工作”，然后是“之后的冲刺”。
为什么会出错：这将计划与优先级混为一谈。下一个冲刺的内容是做出的规划决策 在规划时，这并不是已成定局的事情。当您将产品待办事项视为预先提交的冲刺队列时，您就失去了对学习内容做出反应的能力；每个冲刺只执行队列。
修复：保持产品待办事项的排序 优先级，而不是通过冲刺分配。使用“准备冲刺”标志或待办列表工作顶部的“下一步”部分。冲刺分配发生在计划中，在待办列表工作之外，而不是在待办列表工作中。
3. 让产品待办事项转储到冲刺中期
症状：利益相关者说“这很紧急，我们可以将其添加到当前的冲刺中吗？”总理说是的。在团队未同意的情况下，冲刺待办事项增加了 5 个点。
为什么会出错：冲刺待办事项是团队和 PM（以及利益相关者）之间关于本次冲刺交付内容的合同。单方面添加项目会破坏该合同。该团队没有任何迹象表明这一添加是否现实。原来的冲刺目标变得更难实现。信任被侵蚀。
解决方法：未经团队同意，不会将任何内容添加到冲刺待办事项列表中。如果某事是 确实 紧急情况下，从冲刺中删除其他同等大小的东西。如果团队无法适应，那么紧急的事情就会转到下一个冲刺，或者存在于单独的“支持/中断”能力轨道中。
4. 仅在冲刺计划中精炼工单
症状：冲刺计划运行 3 小时，因为一半的时间花在弄清楚工单的实际含义上。
为什么会出错：冲刺计划的工作是 采摘 做什么，不做什么 理解 该怎么办。如果大部分计划都是“等等，这张票实际上需要什么？”，那么细化就不会发生。细化是让产品待办列表项目达到其应有的状态的工作 准备好了 被捡起；这是一个持续的过程，而不是计划会议活动。
解决办法：每周对产品待办事项列表进行 30 分钟的优化。工单得到澄清、调整大小并标记为“准备冲刺” 之前 规划。规划变成了 30-45 分钟的容量和选择会议，而不是 3 小时的解释会议。
（有关更多信息，请参阅我们的 待办事项细化操作手册.)
产品待办事项中包含哪些内容（以及不包含哪些内容）
健康的产品待办列表包括：
- 前 10-30 项：定义明确、尺寸明确、准备冲刺。每一次细化都焕然一新。
- 中 30-100 件商品：有方向性理解，优先考虑，但尚未准备好。当它们接近顶部时将被完善。
- 底部：“would be Nice”的长尾；想法、环境反馈、半成形的愿望。
臃肿的产品待办列表通常有：
- 500 多件物品，其中大部分已过时
- 18 个月前无人拥有的工单
- “技术债”与没有背景的专题作品混在一起
- 每个人都忘记的现有工单的重复项
- 工单实际上是需要分解的史诗
解决方法：每个季度归档 6 个月内未触及的所有内容。如果重要的话，它会回来。如果没有，那么你就无缘无故地负重了。
冲刺待办事项列表中包含哪些内容
健康的冲刺待办列表工作是：
- 根据实际容量调整大小 （不是理论容量；参见 冲刺能力 并使用焦点系数）
- 过滤为“准备冲刺” 物品；没有需要探索才能开始的模糊工单
- 以 1-2 个冲刺目标项目为锚定：如果完成，就意味着冲刺成功的事情
- 加上支持/较小的物品 来填补容量
- 在冲刺开始时冻结：仅通过贸易添加
一个常见的错误：将冲刺待办列表工作视为一个简单的列表。更好：标记每个项目与冲刺目标的关系。目标关键/目标支持/机会主义。当冲刺中期压力到来时，您知道首先要削减哪些项目。
“准备冲刺”的定义
大多数团队可以做出的最大的改进是：定义“准备冲刺”的含义，并且只让这些项目进入冲刺。
典型的冲刺准备定义：
- 标题清楚地说明了运输的样子
- 列出验收标准（不是“使其发挥作用”）
- 如果需要，可以链接设计/规格/数据
- 团队讲述的故事
- 已识别并解决（或明确已知）的依赖关系
- 描述中没有“待定”或“我们会弄清楚”的内容
不符合此标准的工单尚未准备好，将其放入冲刺中就是要求冲刺滑动。
（我们的 完成生成器的定义 涵盖了 输出 酒吧的一侧。 “冲刺准备”是 输入 边。两者都很重要。）
谁拥有什么
干净的所有权可以避免大部分混乱：
- 产品待办列表：PM 拥有优先级、排序和修饰权。团队致力于细化（规模调整、细分）。
- 冲刺待办事项：团队在冲刺期间拥有它。一旦冲刺开始，任何外部方都不会单方面添加或删除项目。
- 冲刺目标：PM 提议，团队承诺。目标是团队的冲刺合同。
- 细化：共同承担责任； PM 带来工单，团队将其分解并调整大小。
当所有权模糊时，事情就会出岔子。 PM 编辑冲刺待办列表工作 = 破坏合同。团队重写产品待办事项优先级 = PM 被剥夺权力。坚持谁拥有什么。
当你可以简化时
对于非常小的团队（3-5 名工程师，单一产品），正式的产品/冲刺待办列表工作的区别可能会让人感到沉重。一个通常有效的更简单的模型：
- 一个有序列表，按优先级从上到下
- 在冲刺计划中绘制的水平“本次冲刺”线；线上方的项目是本次冲刺，线下方的项目不是
- 每周对前 10 项进行细化
这本质上是相同的模型，但仪式较少。当团队足够小以至于“团队”和“PM”无论如何都在不断地交谈时，它就会起作用。当工程师超过 8 名或 PM 参与度较低时，它就会崩溃。
诚实的总结
产品待办事项 = 开放式、优先级、由 PM 拥有、您要做什么 可能 做。
冲刺 backlog = 关闭、承诺、由团队拥有、您所做的 会 做这个冲刺。
四种模糊模式（愿望清单冲刺、待办列表的冲刺队列、冲刺中期转储、计划细化）导致了团队经历的大部分计划混乱。每个都有一个干净的结构修复。它们都不需要文化变革或高管支持；它们是团队可以在一次回顾中自行做出的决定。
大多数团队可以通过两次回顾来解决 80% 的计划难题：一次是设置“冲刺准备”，另一次是强制冻结冲刺待办列表工作。之后，产品待办事项和冲刺待办事项之间的差异不再是理论上的，而是开始承担责任。
有帮助的工具：
- 冲刺能力计算器：使用焦点因子设置实际的冲刺待办事项大小。
- 冲刺预报员：考虑到产品待办列表和平均速率，什么时候交付？
- 完成生成器的定义：将完成定义（DoD）固定在每个工单上。
- 冲刺 评审议程生成器：冲刺评审围绕“现在做什么”而不是演示剧场。
默认情况下，SprintFlint 干净地拆分产品待办事项和冲刺待办事项。待办事项只有在您拉入时才会进入冲刺，而不是单方面的。 每月50张免费工单: 没有卡。