---

什么是 Scrum 产品待办列表？答案可能让你惊讶！

产品待办列表（Scrum 待办列表） 是管理产品全部已知需求的核心。

包含改善产品、实现目标所需的不断涌现且有序的工作。 需求包括功能、非功能，以及用户体验和界面设计相关功能。

列表包含功能请求及高层故事，也可包括创建测试和开发环境等前提或补充需求，以及修复缺陷、减少技术债务、改善功能的故事。

每个产品共用一个列表，所有团队共享，由产品负责人负责创建、维护和细化。 产品待办列表不回答、也不应回答需求如何开发交付。

那是团队责任：在 Sprint 待办列表中确定并记录实现任务。 两种列表是实体分离的工件，但产品列表事项决定 Sprint 列表内容。

其负责人 Scrum Product Backlog 是产品负责人。Scrum Master、团队和其他相关方共同贡献更全面的故事，支持产品成功。

使用产品待办列表不限制其他工件，例如用户角色总结、流程说明、界面指南、故事板或原型。但这些补充细化列表，不能替代它。

产品待办列表是动态文档。 软件逐步改善，列表也随时间成长。 Scrum 本身不要求独立变更管理流程。产品负责人根据最初最佳理解创建列表初版。

随着每个 Sprint 产品逐渐形成、客户需求知识增加，产品负责人添加、删除并细化需求。

产品负责人确定需求优先级。 优先级越高，应越详细，让团队理解并创建实施任务。

开发人员按需估算规模，故事点是一种可选技术。高优先级故事应细化估算，为规划做准备。

它与普通任务清单有以下区别：

• 故事始终为客户、业务所有者及最终用户增加业务或技术价值，
• 所有故事按优先级从高到低排列，
• 细节程度取决于在列表中的位置，
• 按需用适当技术估算故事规模，
• 列表是动态文档，
• 描述产品工作；详细执行计划属于开发人员的 Sprint 待办列表。

故事为客户、业务和系统增加价值

每个故事必须提供客户价值。 无价值故事纯属浪费，应消除。列表可包含用于以下目的的故事：

• 规定功能和非功能需求，
• 总结发布所需工作的高层拆分，
• 建立非生产开发和演示环境，
• 修复缺陷。

Scrum 产品待办列表示例

某些任务不直接增加功能或业务客户价值，但应通过提高质量、减少技术债务和增强长期可维护性创造价值。

产品待办列表是动态文档

列表在整个项目中变化演进，必要时增加、修改、细化甚至删除故事。需求不再像瀑布那样早期冻结。

最终需求集与软件增量一起迭代形成。

这不同于传统需求工程，却让团队最大化客户价值、最小化资源浪费。

不同细节层次

列表需求的深度和粒度可不同。 只有接下来几个 Sprint 要实施的需求才应更详细。其他故事保持粗粒度，在需要深入理解之前“及时”处理。

过早花资源细化没有意义，因为实施前可能改变或消失。 “及时”处理需求，是 Scrum 应对项目“未知的未知”的杰出益处之一。

产品待办列表不放低层任务

它通常描述产品工作，而非详细执行任务。产品负责人与客户及相关方定义需求，再带入细化或规划会。开发人员负责详细拆分和组织工作。

产品待办列表按优先级排序

所有故事从高到低排序，由产品负责人在团队支持下完成。常考虑客户业务价值、成本、风险和依赖，据此决定随后开发交付什么。

估算产品待办列表条目规模

开发人员可用商定技术估算，例如 Fibonacci 故事点或 S/M/L/XL/XXL 相对大小。Scrum 不要求特定量表，也不要求为所有远期事项估算，后文会详述。估算影响能力规划、Sprint 列表内容及发布计划。

使用待办列表

它需定期关照和细心管理，因为 它是理解软件产品本质的可靠来源.

初期有许多高层故事，未必都高度关联项目成功。 随着 Sprint 推进，产品负责人和团队了解更多。

列表也越来越准确反映产品及团队所学。

初始建立后必须持续维护，包括：

• 描述并新增发现的需求，适当修改或删除现有需求，
• 排序，把最重要的故事放在顶部，
• 通常在细化中准备高优先级故事，供下一规划使用，
• 通常在细化中估算或重新估算故事。

产品负责人确保列表状态良好，但维护是协作过程。 除 Scrum 活动所需时间外，也应预留合理能力持续细化列表。

共同维护有助澄清需求，增强团队对正在形成的产品的认同。