创建产品待办事项列表是 Scrum 框架中最重要的职责之一。它作为需要构建、优化和交付内容的唯一真实来源。与简单的待办事项列表不同，产品待办事项列表是一个动态的、不断演进的产物，反映了市场和用户需求的变化。
本指南将全面介绍如何构建您的初始产品待办事项列表。我们将超越基本定义，深入探讨优先级排序、故事编写和细化的机制。完成本教程后，您将了解如何维护一个能够创造价值并支持敏捷交付的待办事项列表。
理解产品待办事项列表 📋
产品待办事项列表是产品中可能需要的所有内容的有序列表。它是用于跟踪进度和规划工作的主要产物。在 Scrum 中，产品负责人对产品待办事项列表的有效性负责。这意味着他们需要负责对各项内容进行排序，以实现价值最大化。
一个健康的产品待办事项列表的关键特征包括：
- 有序的：项目按价值、风险、优先级或必要性进行排序。
- 演进的：随着产品和环境的变化而不断演进。
- 细化的：位于顶部的项目应清晰明确，并可在冲刺计划阶段被选择。
- 透明的：任何人都可以查看正在考虑的内容及其原因。
前提条件：角色与职责 👥
在填充列表之前，必须清楚了解涉及的人员及其输入内容。产品待办事项列表并非在真空环境中创建。
产品负责人
产品负责人负责内容和顺序。他们代表客户和业务的声音。他们决定哪些内容进入待办事项列表以及何时处理。
开发团队
团队提供技术视角。他们协助估算工作量、识别技术风险并明确验收标准。他们的输入确保了各项内容的可行性。
Scrum 主管
Scrum 主管负责推动流程。他们帮助确保待办事项列表的透明性，并使细化会议顺利进行。他们指导团队实践敏捷方法。
第一步：定义产品愿景 🎯
在添加第一个项目之前，您需要一个目标。产品愿景描述了产品的未来状态。它为待办事项列表提供了明确的方向。
为此，需要：
- 确定目标受众。
- 明确您要解决的问题。
- 概述独特的价值主张。
- 设定未来6到12个月的高层次目标。
这一愿景起到了筛选作用。在考虑新项目时，请问自己：“这是否符合我们的愿景？”如果答案是否定的，该项目就不应列入待办事项列表。
步骤 2：收集需求并创建史诗 📝
史诗是规模较大的工作内容，无法在单个冲刺中完成。它们作为较小工作单元的容器。可以将史诗视为书中的章节。
创建史诗的方法：
- 回顾产品愿景。
- 识别主要主题或功能领域。
- 为每个主题编写高层次的描述。
- 确保每个史诗都有明确的目标。
示例史诗：“用户认证系统”。这个规模太大，无法一次性完成，还需要进一步拆分。
步骤 3：撰写用户故事 🧩
用户故事是产品待办事项列表中的主要工作单元。它们从用户的角度描述一个功能。使用标准格式有助于保持清晰。
用户故事格式
使用以下模板来撰写你的故事：
作为一个 [用户类型]，
我想要 [执行某个操作]，
以便于 [我能够实现某个目标]。
这种结构迫使你关注价值而非技术实现。它确保团队理解工作的为什么背后的原因。
用户故事示例
- 作为一个注册用户，我想要重置我的密码，以便于如果我忘记了密码，我可以重新获得账户访问权限。
- 作为经理，我想要查看每周报告，以便我可以跟踪团队绩效。
- 作为访客，我想要浏览目录，以便我在注册前可以找到产品。
步骤 4：优先级排序技巧 ⚖️
排序待办事项列表是一项持续的活动。你不能一次性完成所有内容。你必须根据价值、成本和风险进行优先级排序。以下是三种常见的框架。
1. MoSCoW 方法
该方法将项目分为四类：
- M必须拥有：对发布至关重要。缺少此项，产品将失败。
- S应该拥有：重要但非关键。如有必要，可以延迟。
- C可以拥有：理想功能。如果时间允许，会是不错的选择。
- W不要拥有：明确排除在当前范围之外的项目。
2. 加权最短作业优先（WSJF）
这在扩展环境中非常有用。它通过考虑以下因素来计算价值：
- 业务价值
- 时间紧迫性
- 风险降低
- 机会赋能
得分最高的项目会被放在待办事项列表的顶部。
3. 价值与努力矩阵
将项目绘制在2×2的网格上。首先优先处理高价值/低努力的项目（快速胜利）。高价值/高努力的项目是主要举措。低价值的项目则被降低优先级。
步骤5：细化与估算 📏
细化（以前称为梳理）是为待办事项列表中的项目添加细节、估算和优先级的过程。这一过程贯穿整个冲刺，而不仅仅发生在计划之前。
细化检查清单
- 故事是否清晰简洁？
- 验收标准是否已定义？
- 技术方案是否已理解？
- 故事是否足够小，可以在一个冲刺内完成？
估算技术
团队通常使用相对大小而非小时数进行估算。这可以减少对准确性的焦虑。
- 计划扑克： 团队讨论故事，并使用卡片投票决定复杂度。
- T恤尺码法： 根据努力程度将项目标记为XS、S、M、L、XL。
- 故事点： 分配一个数值，代表复杂性和努力程度。
步骤6：定义验收标准 ✅
没有验收标准的用户故事是不完整的。这些标准定义了故事被视为完成所必须满足的条件。
有效的验收标准应具备：
- 具体： 清晰且无歧义。
- 可测试： 测试人员应能验证该条件。
- 独立： 每个标准都可以单独测试。
示例：
故事：登录界面
- 系统接受有效的用户名和密码。
- 系统在成功后重定向到仪表板。
- 系统在凭证无效时显示错误消息。
- 输入密码时字段会被隐藏。
维护待办事项列表 🧹
如果不加以维护，待办事项列表就会变成未完成工作的坟墓。必须定期维护以保持其健康状态。
待办事项列表健康指标
| 指标 | 为何重要 | 目标 |
|---|---|---|
| 顶部项目年龄 | 确保最近的优先级变更得到体现 | 少于2个冲刺周期 |
| 精炼率 | 衡量有多少工作已准备好进行规划 | 冲刺容量的20% |
| 故事规模 | 确保项目可在冲刺中交付 | 10-20个故事点 |
应避免的常见陷阱 ⚠️
许多团队因常见错误而在产品待办事项列表上遇到困难。请警惕这些陷阱。
1. 项目过多
保留数千个项目会产生噪音。应聚焦于能带来80%价值的前20%项目。
2. 描述模糊
像“提升性能”这样的项目无法执行。应将其分解为具体任务或故事。
3. 忽视技术债务
不要将技术债务藏在单独的桶里。应将其作为待办事项列表中的一项，以便与功能一起优先排序。
4. 静态排序
待办事项列表必须不断变化。如果市场条件发生变化，顺序也必须随之调整。不要将列表顶部视为永久不变的法则。
待办事项列表 vs. 冲刺待办事项列表
必须清楚区分产品待办事项列表和冲刺待办事项列表。混淆两者会导致范围蔓延和规划失败。
| 功能 | 产品待办事项列表 | 冲刺待办事项列表 |
|---|---|---|
| 负责人 | 产品负责人 | 开发团队 |
| 范围 | 整个产品 | 仅当前冲刺 |
| 稳定性 | 动态（随时可变更） | 稳定（冲刺期间不变更） |
| 详细程度 | 可变（顶部项目详细） | 高（所有项目详细） |
常见问题 ❓
产品待办事项列表中应该有多少项？
没有固定数量。这取决于产品生命周期。但请确保前10-20项已充分细化，并准备好用于下一个冲刺。
开发团队可以向待办事项列表添加项目吗？
可以。虽然产品负责人负责排序，但开发团队可以根据技术需求或用户反馈提出建议。他们会与产品负责人一起评审这些建议。
冲刺中未选择的项目会怎样？
它们会保留在产品待办事项列表中。在下一次计划会议中将重新排序优先级。它们不会过期或消失。
我们应该估算待办事项列表中的每一项吗？
不需要。估算所有项目是浪费时间。只需估算位于顶部且可能很快会被处理的项目。低优先级项目可使用粗略估算。
我们应该多久进行一次待办事项列表的细化？
细化应作为持续进行的活动。每个冲刺安排一次专门的会议是常见做法。这能确保团队为下一次计划会议做好准备。
总结 🏁
构建产品待办事项列表是一个迭代过程。它需要持续的沟通、优先级排序和细化。通过遵循本教程中概述的步骤，您可以创建一个可靠的路线图，指导您的产品发展。
请记住，目标不是立即创建一个完美的列表。目标是创建一个动态的文档，引导团队持续交付价值。从小处开始，频繁迭代，始终关注用户需求。
通过维护良好的待办事项列表，您的Scrum团队可以自信地应对复杂性，并持续交付高质量的产品。
