产品待办列表：如何有效构建并确定优先级
产品待办事项列表（Product Backlog）是敏捷开发的引擎。每一个可能被构建的功能、漏洞修复、改进和技术任务都存在于待办事项列表中，它们按优先级排序，经过估算，并随时准备被纳入冲刺（Sprint）。
管理良好的待办事项列表是成熟敏捷团队最明显的标志之一。如果待办事项列表被忽视，其中充斥着数百个条目，且许多条目无关紧要、优先级不明确且没有估算，那么这无疑是团队流程需要改进的最明确信号之一。
本指南将介绍如何从零开始构建产品待办事项列表，如何维护它，以及如何确保它真正推动开发，而不是沦为一个无人管理的想法堆积场。
什么是产品待办事项列表？
在 Scrum 中，产品待办事项列表是一个有序的列表，包含了所有可能用于改进产品的任务。它由产品负责人（Product Owner）拥有，是团队工作内容的唯一事实来源。
待办事项列表包含：
- 用户故事（User stories）：从用户角度描述的功能
- 漏洞修复（Bug fixes）：需要解决的缺陷
- 技术债务（Technical debt）：对代码质量、架构或基础设施的改进
- 探针（Spikes）：在承诺开发某项功能前，为降低不确定性而进行的调研任务
- 非功能性需求（Non-functional requirements）：性能、安全性、可访问性方面的改进
待办事项列表中的每一项都必须有其存在的理由，即它代表了对用户或业务的潜在价值。不再具有价值的条目应该被删除，而不仅仅是降低优先级。
产品负责人的角色
产品负责人（PO）负责待办事项列表。这意味着：
- 在识别出新需求时添加条目
- 移除不再相关的条目
- 始终保持待办事项列表按优先级排序
- 确保列表顶部的内容已准备就绪，供开发团队开展工作
PO 不会孤立地创建待办事项列表。输入来自用户、利益相关者、开发人员和数据。但 PO 对优先级拥有最终决定权。
这种单一所有者模式是敏捷最重要的原则之一。由委员会管理或通过委员会式投票管理的待办事项列表往往倾向于妥协，而非明确的优先级排序，最终导致团队试图同时处理所有事情。
编写优质的待办事项条目
"User can export data"
"As a user I can filter"
"Add pagination to list"
用户故事格式
标准的用户故事格式为：
作为一个 [用户类型]，我想要 [某项操作]，以便于 [某种收益]。
例如：“作为一个项目经理，我想要按负责人筛选任务，以便于一眼就能看到团队的工作量。”
这种格式迫使你明确谁受益、他们需要什么以及为什么需要。这三个背景要素可以防止因错误的原因而构建功能。
验收标准
每个待办事项条目都应有验收标准：即必须满足的特定、可测试的条件，该条目才会被视为“完成”。
上述筛选任务故事的验收标准示例：
- 用户可以同时按一个或多个负责人进行筛选
- 筛选后的视图实时更新，无需重新加载页面
- 当用户离开并返回时，筛选状态得以保留
- 选择“未分配”时，显示未分配的任务
没有验收标准，“完成”就是未定义的。有了验收标准，开发人员和测试人员都能准确知道需要验证什么。
INVEST 原则
好的用户故事应符合 INVEST 原则：
| 字母 | 含义 |
|---|---|
| I | Independent（独立的）：可以在不依赖其他故事的情况下进行开发 |
| N | Negotiable（可协商的）：细节可以在讨论中调整 |
| V | Valuable（有价值的）：为用户或业务提供价值 |
| E | Estimable（可估算的）：团队可以估算所需的工作量 |
| S | Small（小的）：可以在一个冲刺内完成 |
| T | Testable（可测试的）：有明确的验收标准 |
不符合这些标准的故事在进入冲刺前需要进行细化。这通常发生在故事太大、太模糊或无法独立交付的情况下。
待办事项列表优先级排序技术
优先级排序是产品判断力与数据交汇的地方。有几种框架可以为优先级决策提供结构。
MoSCoW 方法
将每个条目归类为 Must have（必须有）、Should have（应该有）、Could have（可以有）或 Won’t have（本次发布不包含）。这创建了一个简单的四级优先级系统，利益相关者可以理解并参与其中。
RICE 评分
RICE 代表 Reach（触达范围）、Impact（影响力）、Confidence（信心指数）、Effort（工作量）。每个条目根据这些维度进行评分，并按 RICE 分数排名：(Reach × Impact × Confidence) / Effort。
这是一种定量优先级排序方法。当你拥有关于触达范围和影响力的数据，并且想要一个比单纯凭直觉更具说服力的排名时，这种方法非常有效。
价值与工作量矩阵
将每个待办事项条目绘制在 2x2 矩阵上：一个轴是价值，另一个轴是工作量。高价值、低工作量的象限是“速赢”项目，应优先考虑。低价值、高工作量的象限则是删除的候选对象。
Kano 模型
Kano 模型根据功能如何影响用户满意度对其进行分类：
- 基本需求：缺失会导致不满，存在则是预期的（必须有）
- 性能需求：越多越好（核心功能）
- 魅力需求：意想不到的功能，能显著提高满意度
该框架有助于平衡“必须有”的功能与创新。
待办事项列表梳理（细化）
待办事项列表梳理（Backlog Grooming），也称为待办事项细化（Backlog Refinement），是一个循环过程，用于审查、更新和改进待办事项条目。在 Scrum 中，它通常在每个冲刺期间作为一次独立的会议进行。
梳理会议包括：
- 审查新条目：自上次梳理以来添加的条目。它们编写得清晰吗？是否有验收标准？
- 估算条目：团队对列表顶部的条目进行工作量估算，以便为冲刺计划做好准备。
- 拆解大型条目：将史诗（Epics）和大型故事拆解为更小的、适合冲刺的任务。
- 修剪：移除不再相关、过时或重复的条目。
- 重新排序：根据新信息、利益相关者反馈或业务优先级的变化调整顺序。
健康的梳理节奏意味着你的待办事项列表顶部始终为下一个冲刺做好准备：已编写、已估算且已排序。
保持待办事项列表的健康
一个无限增长且不进行修剪的待办事项列表会成为一种负担。团队会停止信任它，因为他们知道里面充满了没人打算构建的条目。以下是健康待办事项列表的标志以及如何维护它们。
健康待办事项列表的标志
- 前十到十五个条目已细化并准备好进入冲刺
- 所有条目都有清晰的标题和验收标准
- 列表中没有超过六个月且从未被排在顶部附近的条目
- 团队中的每个人最近都阅读过列表顶部的内容
- 条目被定期移除，而不仅仅是添加
“如果六个月内不会构建，就删除它”规则
许多团队背负着数百个他们根本不打算在未来六个月内构建的待办事项。这会产生干扰，使真正的优先级更难被发现。一个有用的规则是：如果一个条目在待办事项列表的底部三分之一处停留了六个月，请将其归档或删除。如果它真的很重要，它会再次出现。
分离“冷藏库”（Icebox）
一些团队维护一个“冷藏库”：一个存放想法和未来潜在工作的独立集合，明确不属于活跃的待办事项列表。冷藏库中的条目不进行优先级排序、不细化、也不估算。它们只是被记录下来以备将来考虑。
这可以防止冷藏库污染活跃的待办事项列表，并使活跃列表更小、更整洁、更值得信赖。
产品待办事项列表 vs. 冲刺待办事项列表
产品待办事项列表和冲刺待办事项列表相关但有所不同：
| 产品待办事项列表 | 冲刺待办事项列表 | |
|---|---|---|
| 范围 | 所有可能构建的内容 | 团队承诺在本冲刺中完成的内容 |
| 所有者 | 产品负责人 | 开发团队 |
| 持续时间 | 持续进行，不断演变 | 一个冲刺（1–4 周） |
| 详细程度 | 不等（顶部详细，底部粗略） | 所有条目均已完全细化 |
| 大小 | 可能有数百个条目 | 通常 10–20 个条目 |
在冲刺计划会议上，团队将条目从产品待办事项列表的顶部拉入冲刺待办事项列表。这就是为什么产品待办事项列表的顶部必须始终准备就绪的原因：冲刺计划会议无法为整个冲刺实时细化故事。
相关阅读：冲刺计划：如何开展高效会议 和 用户故事地图指南
管理产品待办事项列表的工具
| 工具 | 适用场景 | 待办事项列表功能 | 价格 |
|---|---|---|---|
| Jira | 大型工程团队 | 史诗、故事、冲刺、报告 | $7.75/用户/月 |
| Linear | 产品工程团队 | 简洁 UI、周期、路线图 | 免费 / $8/月 |
| TasksBoard | Google Workspace 团队 | 看板、共享任务列表 | 免费 / 高级版 |
| Notion | 灵活的团队 | 自定义数据库、视图 | 免费 / $8/月 |
| Trello | 小型团队 | 卡片、列表、标签 | 免费 / $5/月 |
| Asana | 跨职能团队 | 组合、时间轴、工作量 | 免费 / $10.99/月 |
对于使用 Google Workspace 的团队，TasksBoard 提供了一种简单直接的方法，将待办事项条目作为共享的 Google Tasks 列表进行管理，并配有看板视图，无需专用项目管理平台的繁琐开销。
常见问题解答
谁拥有产品待办事项列表？
产品负责人拥有待办事项列表，并对其内容、顺序和可用性负责。开发团队提供估算和技术输入，但 PO 做出最终的优先级决策。
待办事项列表应该多久梳理一次？
大多数 Scrum 团队每个冲刺梳理一次，大约花费冲刺容量的 10% 用于细化。对于两周的冲刺，这大约是每周 90 分钟。
产品待办事项列表应该有多大？
没有统一的答案，但超过 100 个条目的列表通常表明旧条目没有被修剪。重点在于保持前 20–30 个条目经过细化并准备就绪。其余条目可以不那么详细。
在产品待办事项列表的背景下，什么是史诗（Epic）？
史诗是一个大型用户故事，太大而无法在一个冲刺内完成。在待办事项列表细化过程中，史诗会被拆解为更小的故事。它们充当相关功能的组织容器。
如何处理产品待办事项列表中的漏洞？
漏洞被视为待办事项条目，并与功能一起进行优先级排序。关键漏洞通常会跳到顶部。次要的视觉漏洞可能排在许多功能之下。一些团队维护一个单独的漏洞列表，仅在优先级排序时将其与待办事项列表合并。
产品待办事项列表和路线图（Roadmap）有什么区别？
路线图向利益相关者传达高层级的计划功能和时间表。待办事项列表是内部的、运营性的工作列表，按开发优先级排序。路线图源自待办事项列表，但呈现的是适合外部受众的简化、有时限的视图。
使用 TasksBoard 管理你的待办事项列表
产品待办事项列表只有在团队能够看到、更新并信任它时才有用。TasksBoard 将共享的 Google Task 列表转换为可视化的看板，为你的团队提供了一种简单、协作的方式来管理待办事项条目，而无需复杂的设置。
为你的待办事项阶段（冷藏库、待办事项、进行中、已完成）创建列表，添加带有描述和截止日期的任务，并与团队中的每个人共享该看板。这是从“我们接下来要构建什么？”到获得清晰、共享答案的最短路径。
