Product Backlog 和 Sprint Backlog 的核心区别在于层级与承诺：前者是产品层面持续维护的待办来源，回答“接下来可能做什么”；后者是从中选取、为当前迭代承诺完成的工作及交付计划，回答“这一轮具体做什么、怎么做”。理解这一关系，能帮助团队在迭代运行中正确放置需求、处理变更与未完成工作。
要点总览（TL;DR）
- Product Backlog 是产品级、持续维护的待办来源，由产品负责人按价值排序；Sprint Backlog 是从中选取、为当前迭代承诺完成的工作及任务计划，由开发团队在迭代内维护。
- 两者是来源与选取的关系：Product Backlog 条目可粗可细、随时增删重排；Sprint Backlog 条目需细化到可执行任务，迭代开始时建立、结束时关闭。
- 迭代计划会从 Product Backlog 顶部按优先级选取条目并拆解为任务；迭代中新增需求回到 Product Backlog 重新排序，不直接插入当前迭代。
- 未完成工作需重新评估剩余价值与优先级后放回 Product Backlog，不默认自动结转，避免迭代范围膨胀。
- 判断条目归属看它是否在当前迭代承诺范围内；工具中把产品级待办与迭代级任务分层存放并保留追溯关系，ONES 的需求池与迭代规划可承载这一分工。
两者在敏捷流程中各自承担什么角色
Product Backlog 是产品级的待办来源，由产品负责人维护并持续排序。它承载来自用户反馈、业务目标、技术改进等各方的需求，条目可以粗到一句想法，也可以细到带验收标准的需求说明。它的价值在于让团队始终能看到“下一步最值得做的事”，并随市场与业务变化不断增删调整。
Sprint Backlog 是迭代级的执行清单。团队在迭代计划会上从 Product Backlog 顶部按优先级选取条目，经评审与拆解后形成当前迭代要完成的工作，加上交付这些工作的任务计划。它只在迭代周期内存在，由开发团队在日常执行中维护，回答的是“这一轮我们承诺交付什么、通过哪些任务完成”。
两者是来源与选取的关系，而非并列的两份需求池。Product Backlog 是水库，Sprint Backlog 是从中舀出的一桶水；前者持续存在并不断变化，后者在迭代开始时建立、结束时关闭。把两者当成平行的两份清单，往往会导致需求重复登记、优先级冲突和进度失真。
| 维度 | Product Backlog | Sprint Backlog |
|---|---|---|
| 流程位置 | 产品规划与需求排序阶段 | 迭代计划与迭代执行阶段 |
| 主要职责 | 维护待办来源、确定优先级 | 承诺迭代范围、组织任务交付 |
| 维护角色 | 产品负责人 | 开发团队 |
| 时间跨度 | 持续存在，跨迭代演进 | 限定在一个迭代周期内 |
同口径差异对照：内容、负责人、变更与生命周期
把两个概念放到同一组维度下比较，差异会更清晰。下表按内容范围、排序依据、负责人、变更频率、生命周期和完成标准逐项对照，便于在实际管理中快速判断某个条目应归入哪一份清单。
| 对照维度 | Product Backlog | Sprint Backlog |
|---|---|---|
| 内容范围 | 产品全部待办，条目可粗可细，包含需求、改进、缺陷修复等 | 当前迭代选取的条目，需细化到可执行任务，含任务拆解与交付计划 |
| 排序依据 | 按业务价值、优先级、依赖关系等综合排序，由产品负责人决定 | 按迭代目标与任务依赖安排执行顺序，由团队在迭代内调整 |
| 负责人 | 产品负责人 | 开发团队 |
| 变更频率 | 持续变更，随时可增删与重排 | 迭代内保持稳定，仅在范围澄清或必要调整时变动 |
| 生命周期 | 持续存在，随产品演进而长期维护 | 迭代开始时建立，迭代结束时关闭 |
| 完成标准 | 条目达到“可进入迭代”的准备程度，如描述清晰、验收标准明确 | 迭代目标达成，任务完成并满足约定的完成定义 |
需要留意的是，Product Backlog 条目的细化程度是渐进的：靠近顶部的条目通常更细，便于近期规划；靠后的条目可以保持较粗的粒度，等优先级上升后再补充细节。Sprint Backlog 则要求条目在迭代内足够具体，团队能据此直接开展工作并跟踪进度。
迭代运行中两者如何衔接
衔接的起点是迭代计划会。产品负责人从 Product Backlog 顶部按优先级选取候选条目，与团队共同评审需求内容与验收标准，确认本轮迭代的目标与范围。选取完成后，团队把条目拆解为具体任务，估算工作量并安排执行顺序，形成 Sprint Backlog。
迭代进行中，团队围绕 Sprint Backlog 中的任务推进工作，通过看板等方式跟踪任务状态。此时若出现新的需求或想法，通常的做法是回到 Product Backlog 重新排序，由产品负责人评估其优先级，而不是直接插入当前迭代。这样既保护了迭代承诺的稳定性，也让新需求在下一轮规划中有序进入。
迭代结束时，未完成的工作需要重新评估：确认剩余价值、阻塞原因和优先级变化，再决定放回 Product Backlog 的哪个位置，而不是默认自动结转到下一迭代。默认结转容易让迭代范围不断膨胀，也会掩盖计划与实际能力的偏差。
示例：某团队在迭代计划会上从 Product Backlog 顶部选取“订单导出支持按时间筛选”等三个需求，拆解为前端页面、接口开发、测试验证等任务形成 Sprint Backlog。迭代中期业务方提出“导出增加权限控制”，产品负责人将其登记到 Product Backlog 并评估优先级，安排进下一轮候选；迭代结束时“接口开发”任务未完成，团队评估后将其拆小并放回 Product Backlog 待重新排期。
常见混淆点与判断方法
判断一个条目属于哪份清单，最直接的口径是看它是否在当前迭代的承诺范围内。属于本轮迭代要交付的内容，归入 Sprint Backlog；尚未进入本轮承诺、仍在等待排序的，留在 Product Backlog。用这组问句可以快速定位：
- 这个条目是否已在本轮迭代计划中承诺交付？是，则属于 Sprint Backlog；否，则属于 Product Backlog。
- 这个条目是否已有明确的任务拆解和负责人安排？有，说明已进入迭代执行；没有，说明仍在待办来源中等待细化。
- 这个变更是否需要产品负责人重新排序？需要，说明它应回到 Product Backlog；不需要且属于范围澄清，才在 Sprint Backlog 内调整。
- 这个条目在迭代结束后是否还需要继续跟踪？需要长期跟踪的，应回到 Product Backlog 重新评估。
另一类混淆来自用途错位。把 Sprint Backlog 当作长期需求清单，会让迭代边界模糊，历史任务不断堆积；把 Product Backlog 当作排期表，则会过早锁定时间，失去按价值重新排序的灵活性。需求池的收集、整理与排序属于 Product Backlog 的管理范畴，迭代内的任务执行与状态跟踪属于 Sprint Backlog 的范畴，两者分开维护，才能各自发挥应有作用。
在工具中如何分别承载两份 Backlog
概念上的分层需要落到工具的结构上：产品级待办与迭代级任务分开存放，同时保持条目之间的追溯关系。产品级待办放在需求池中统一收集与排序，迭代级任务放在迭代空间中承载执行，需求条目与拆解出的任务之间保留关联，这样从需求到任务的路径清晰可查，评审和复盘时也能回溯来源。
在 ONES 中，可以使用工单收集和整理来自各方的反馈，处理工单并快速转化为需求，整理出产品 Backlog；产品负责人可根据需求优先级，将产品待办列表中的需求规划至对应迭代，并在迭代计划会议上与团队共同进行需求评审。对当前迭代要完成的需求与验收标准达成一致后，设计、研发、测试人员可利用子任务将需求进行拆分，方便后续处理和跟踪；迭代过程中，团队成员围绕迭代要完成的需求完成自己拆解的任务，并通过敏捷看板管理任务状态。ONES Project 支持建立需求池、规划迭代，可将需求和相关任务规划至迭代并分配负责人，并提供看板、燃尽图等工具实时掌控当前进度。
迭代结束后，未完成项的处理建议在工具中保留人工评估环节：由团队确认剩余工作与优先级，再决定放回需求池的排序位置或拆分为更小的条目。这样既保持了 Product Backlog 作为唯一待办来源的完整性，也避免未完成工作未经评估就自动进入下一迭代，导致范围失控。
常见问题
迭代进行到一半，业务方提出一个紧急需求，应该放进 Sprint Backlog 还是 Product Backlog？
通常先登记到 Product Backlog，由产品负责人评估价值与优先级，再决定是否影响当前迭代。如果团队判断该需求必须在本轮交付，需要与团队明确替换掉哪项已承诺的工作，并同步调整 Sprint Backlog，保持迭代范围与团队实际能力一致。直接插入而不做取舍，容易让迭代目标失焦。
迭代结束后没做完的任务，可以直接带到下一个迭代吗？
建议先评估再决定去向，而不是默认结转。团队需要确认剩余工作量、未完成原因以及优先级是否发生变化，再决定放回 Product Backlog 的哪个位置，或拆成更小的条目重新排期。未经评估的自动结转会让迭代范围逐轮累积，也会掩盖计划与实际能力的偏差。
Product Backlog 里的条目需要一开始就写得很细吗？
不需要。靠近顶部的条目通常细化到描述清晰、验收标准明确，便于近期规划；靠后的条目可以保持较粗的粒度，等优先级上升后再补充细节。Sprint Backlog 中的条目则要求足够具体，团队能据此拆解任务、估算并跟踪进度。
团队规模较小、没有专职产品负责人时，两份 Backlog 怎么分工维护？
可以由承担产品职责的角色统一维护 Product Backlog 的排序，开发团队在迭代内维护 Sprint Backlog。关键在于排序决策与执行跟踪由不同环节负责：排序需要综合业务价值与依赖关系，执行跟踪关注任务状态与阻碍。角色可以兼任，但两类决策的记录要分开，避免需求登记与任务执行混在同一份清单里。
在 ONES 中如何把产品待办和迭代任务分开管理？
可以用工单收集各方反馈并转化为需求，整理出产品 Backlog；产品负责人按优先级把需求规划至对应迭代，团队在迭代计划会上评审需求与验收标准，再用子任务拆分需求。迭代过程中通过敏捷看板管理任务状态。ONES Project 支持建立需求池、规划迭代，可将需求和相关任务规划至迭代并分配负责人，并提供看板、燃尽图等工具跟踪进度。
