The Scrum Framework — 第二版

本章保留第二版的历史与实践教学语境。下方目录也提供第三版课程。

---

Scrum 产品待办列表：团队如何在敏捷项目中创造价值

您的敏捷项目是否还没有充分发挥潜力？您或许正绞尽脑汁，想像教练指挥团队一样，灵活地完善 Scrum 方法。现在该重新关注一个可能改变局面的组成部分（Scrum框架的主要组成部分），那就是 Scrum 产品待办列表。这一强大工具常被低估或误解，掌握它却能引导您的敏捷项目迈向成功。准备好用这种方法改善产品交付了吗？这值得您投入。跟随我们了解它的作用、最佳实践，以及它如何成为项目管理中的制胜法宝。您是否想释放尚未挖掘的潜力？让我们经验丰富的培训师，陪您一起学习这组精彩的 Scrum 产品待办列表课程！

定义：Scrum 产品待办列表，是在敏捷项目中为交付和改进产品而需要完成的工作条目的有序列表。 正如教练指导学生进行体育运动，待办列表也为 Scrum 团队提供必要支持。有效管理这一工具，需要定期细化条目、确定优先级，保持透明，与产品目标一致，并利用电子工具方便搜索和筛选。删除或归档旧工单时，也要妥善沟通变化，让待办列表保持可管理的规模。

最简单地说，Scrum 产品待办列表就像项目中一系列需要完成的任务。 它取代传统的需求规格工件。这些条目可以是技术性的，也可以以用户为中心。Scrum 产品负责人拥有 Scrum 产品待办列表（更多信息请参阅 Scrum Product Owner）。Scrum Master、Scrum 团队和其他利益相关者，就像帮助学生做好准备的培训师，共同促成一份广泛而完整的待办清单。

使用 Scrum 产品待办列表，并不意味着 Scrum 团队不能创建和使用其他工件。例如，可以补充用户角色摘要、工作流程描述、用户界面指南、故事板或界面原型。这些工件并不取代 Scrum 产品待办列表，而是补充并细化其内容，体现对全面开展项目开发的投入。

在团队支持下，Scrum 产品负责人在 Sprint 规划会中使用产品待办列表，向团队说明排在前面的条目。（请参阅我们的 Scrum示例）随后，Scrum 团队确定在下一轮 Sprint 中能够完成哪些条目，优化产品交付。

每份 Scrum 产品待办列表都有一些特征，使其区别于简单的待办清单。这些特征为 Scrum 学习者提供指导和方向，就像教练带领团队走向胜利。

• 每个产品待办列表条目都应直接或间接贡献价值，包括质量、降低风险、技术改进或学习。
• Scrum 产品待办列表的条目按优先级排列。
• 细节程度取决于条目在 Scrum 产品待办列表中的位置。
• 按需要估算条目规模，以支持即将作出的决策和预测。
• Scrum 产品待办列表是一份持续演进的文档。
• 具体实施任务通常属于开发人员的 Sprint 计划；产品待办列表始终聚焦产品工作与成果。

定义 Scrum 待办列表

每个成功的敏捷项目都以产品待办列表为核心，Scrum 也不例外。简单地说，产品待办列表是一份有序条目清单，也称产品待办列表条目（PBI），产品开发团队需要完成这些工作，才能交付成功的产品。在 Scrum 项目中，待办列表的重要性就像教练对学生的投入。产品负责人负责确定工作优先级，确保有效交付产品。

待办列表包含已知为交付产品所需的所有条目，例如功能、缺陷、技术债务和知识获取等。 这是一种随着持续反馈循环逐步形成、不断演进的工件。起初可能包含一长串高层次需求或史诗。团队开始处理各个史诗时，会将其拆成更小、细节更丰富的故事。每个条目随后都应足够小，让开发人员能在一个 Sprint 中完成，体现 Scrum 流程的敏捷性。产品待办列表也是 Scrum 方法中不可或缺的规划工具，支持迭代和增量软件开发活动。对参与其中的软件开发人员和 Scrum Master 而言，它像一份课程路线图，列出开发流程所需的敏捷领导策略。

产品待办列表是成功敏捷项目，包括 Scrum 项目的核心组成部分。它是一份有序条目清单，开发团队（其中包括用户体验专家）需要完成这些条目，才能交付符合高标准的产品。它涵盖所有已知产品需求，并通过反馈循环不断演进；案例研究常说明其关键作用。产品负责人对待办列表排序负责，帮助团队聚焦有价值的工作，而开发人员预测每个 Sprint 能完成什么。作为 Scrum 方法中的重要规划工具，它支持从复杂软件开发到敏捷领导课程等各种任务。

待办列表需要的照料，就像花园要茂盛生长所需的关怀，必须精心管理。项目开始时，Scrum 团队及产品负责人会像拟定课程安排一样，把容易想到的事项先记录下来。这几乎总能为首轮 Sprint 提供足够工作，就像软件开发人员开始着手新功能时的第一个 Sprint。

使用 Scrum 产品待办列表

Scrum 产品负责人承担职责和责任，确保产品待办列表保持良好状态，就像经验丰富的软件开发人员确保代码高效一样，两者相辅相成。本版在运用 Scrum 框架时，将团队约 10% 的容量作为细化活动（讨论、估算等）的参考，而非要求每个团队都必须如此分配；这就像专家为专业发展课程预留时间。

初步建立之后，Scrum 产品待办列表需要持续维护，正如持续发挥敏捷领导作用一样，过程包括以下步骤：

• 发现新条目时，描述并加入列表；根据需要修改或删除现有条目。
• 为 Scrum 产品待办列表排序，把最重要的条目移到最前面。
• 为下一次 Sprint 规划会准备高优先级条目
• 估算（或重新估算）Scrum 产品待办列表的条目

共同维护 Scrum 产品待办列表，不仅帮助澄清需求，也让 Scrum 团队认同并投入其中，就像成功的用户体验策略一样。

就像课程大纲中的要素，每个 Scrum 产品待办列表条目都必须具有某种客户价值。无法合理说明其对产品价值有何贡献的条目可以删除，但也应允许间接支持价值的工作。列表可以包含探索客户需求和各种技术方案的条目、功能性与非功能性要求、产品上线所需工作，以及环境搭建或缺陷修复等其他事项。就像课程中的案例研究，一些任务虽不直接增加价值，却能确保长期质量改进、减少事故。

Scrum 产品待办列表的特点

持续演进的增值条目列表

Scrum 产品待办列表就像可以定期更新的敏捷领导课程，在整个项目过程中都可能变化。需要时加入新需求，如同软件开发人员添加新功能；现有需求可以修改、定义得更详细，甚至舍弃。这种动态方式有别于传统需求工程，却能最大限度提升客户价值、减少开发工作量。

不同的细节程度

就像课程大纲有不同的详略层次，Scrum 产品待办列表中的需求也有不同粒度。计划在接下来几个 Sprint 之一实施的需求，才会详细定义，其他需求则保持概括。这种方式高效而敏捷，因为它减少了投入在实施前很可能变化的规格说明上的时间与精力。

为下一项决策提供足够细节

产品待办列表需要具备足够细节，以支持下一项决策，尤其是可能很快被选中的条目。它不必预先列出每个底层实施任务。随着学习深入，团队与客户及利益相关者共同澄清需求，由开发人员决定如何把所选工作拆成任务。他们确保妥善分配相关资源，始终牢记为所开发的服务增加价值这一使命。

产品待办列表排序

所有条目都要确定优先级，Scrum 产品待办列表据此排序。Scrum 产品负责人在团队帮助下完成排序，像精心整理一样，根据附加价值、成本和风险等因素微调优先级。反复排序使他们能够迅速决定下一步该做什么。

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

开发人员按需要，采用故事点等共同方法估算产品待办列表条目的规模；不必预先估算整份不断演进的列表。这种估算（更多内容请参阅 Scrum 投入估算），就像准备新版软件，随后既可用于确定产品待办列表条目的优先级，也可用于规划发布。

逐步准备

把产品待办列表想象成旅行准备：我们需要逐步打点行李，提前办好护照和签证，确保旅行计划顺利执行。区别只在于，这里的旅行计划是我们提供的服务，而使用服务的人就是项目利益相关者。

归属与责任

任何敏捷项目都必须在早期建立产品待办列表。但此后在各个 Sprint 中，维护和细化列表的归属与责任主要由产品负责人承担。细化是持续进行的 Scrum 工作，可以贯穿整个 Sprint；另行命名的细化会议并非强制 Scrum 事件。这就像不断更新应用版本以提高透明度，前提是避免变成过度的微观管理。

假设您的团队负责一个敏捷项目，开发实时显示股市数据的应用。应用的某个版本在高负载时响应缓慢。在这轮迭代中，团队应优先处理这类紧迫问题，将其作为具体产品条目加入待办列表，以便新数据上传时能够快速处理。

承担待办列表的归属与责任，有时会让产品负责人觉得是额外负担，仿佛在整理一份不断增长的任务清单。但他们必须了解业务需要和客户需求，并使之与软件开发活动保持一致，努力协调这些不同要素。

产品待办列表管理是跨职能群体之间的沟通工具，促进利益相关者交流，提高实现目标的进展透明度。它就像面向所有参与者的服务路线图，让大家随时了解情况。

理解产品负责人对 Scrum 团队产品待办列表的归属和维护作用，对保持推进势头与专注至关重要。正如每版软件都需要认真更新，这一工具也一样。现在来进一步看看它如何运作。

在 Scrum 中，产品负责人有责任代表利益相关者建立并维护产品待办列表。他们必须确保这一 Scrum 核心资源反映利益相关者的利益，并包含下一轮 Sprint 所需的条目。他们与利益相关者协作，了解需求、识别业务目标，再转化为可执行的 PBI。（产品待办列表条目）

• 《年度敏捷状态报告》显示，超过 70% 的受访组织偏好采用 Scrum 或 Scrum 混合方法进行敏捷项目管理，说明产品待办列表应用广泛。
• 同一报告显示，改善团队可管理性，包括维护细化充分的产品待办列表，是采用敏捷实践的五大原因之一。
• 《Journal of Systems and Software》的一项研究发现，成功的待办列表管理能够提高项目成功率，部分情况下提升幅度高达 30%。

产品负责人的作用

产品负责人必须具备较强领导能力和愿景，清楚优先级，并掌握市场趋势及客户需求信息。他们还应能平衡不同利益相关者之间相互竞争的要求，同时专注实现项目目标。最终，他们负责最大限度提升最终用户从产品和服务中获得的价值。

Scrum 团队的其他成员，即开发团队和 Scrum Master，积极参与创建和细化产品待办列表。他们身处实践一线，确保项目使命得到贯彻，并以宝贵资源和见解塑造迭代。细化过程中，开发团队与产品负责人协作，讨论范围、可行性、技术细节和交付时间。他们共同制定可融入产品的解决方案，提高产品准确性，并进一步改善其为用户带来的收益。

Scrum 团队的参与

例如，某个 PBI 可能需要大幅修改数据库，而在给定 Sprint 时间内不可行，开发团队成员就必须传达这一信息，以便作出调整，或结合产品负责人对待办列表排序的意见修改优先级。在许多高度重视产品交付准确性和及时性的行业，这一过程至关重要。

团队成员应能完整查看所有 PBI，包括用户故事（更多内容请参阅 Scrum用户故事）、技术探索任务、测试发现的缺陷等。这种透明度帮助他们在更大项目需求背景下，理解各个 PBI 如何支持即将到来的 Sprint 目标，也让他们更全面地了解生产流程和相关产品的复杂细节。

Scrum Master 帮助团队有效开展细化，无须规定额外的强制活动。他们发挥协同与合作的优势，消除阻碍进展的因素，专注于确保团队有效实现目标。

Scrum 框架中的各个角色必须有条理、相互配合地工作。以下列出各角色在创建和细化产品待办列表中的具体任务，包括提出解决方案，以确保不同行业准确交付最终产品。

需要强调的是，在产品待办列表细化过程中，成员应努力围绕即将到来的 Sprint 目标形成共同、以人为本的理解。有不清楚的地方，应在细化早期提出问题，不要等到 Sprint 开始后才造成潜在延误。

如果反馈来自利益相关者、客户等多个来源，产品负责人有责任平衡相互竞争的需求，同时聚焦于实现符合项目目标的最终用户目标。开发团队应与其保持开放沟通，确保各项目标在当前 Sprint 背景下切实可行。

产品待办列表是任何成功敏捷项目的重要组成部分。因此，Scrum 团队所有成员都积极参与创建和细化。成员之间清晰沟通、保持透明和协作，是成功落实的关键，使团队获得良好管理生产流程的收益。

敏捷项目要取得成功，Scrum 团队必须有定义清楚的产品待办列表。这不仅明确了交付有价值成果的过程，也让利益相关者理解产品现状与发展轨迹。产品的复杂细节及其与更大目标的联系，推动着待办列表细化。

创建与细化流程

产品待办列表细化是一项持续活动，把条目拆解并进一步定义为更小、更精确的条目。细化工作可以贯穿整个 Sprint；Scrum 并不要求另行安排细化事件。细化流程有助于为各行业创建解决方案，提高产品准确性与有效性。

创建 Scrum 产品待办列表的过程从确定需求开始。团队准备充分，并共同关注最终目标，能增强这一方法的好处，进而创建满足特定行业需要的产品。

Scrum 团队强调的一项基本实践，是定期整理待办列表。 Scrum 整理（待办列表细化）会议 确保待办列表及时更新、优先级合理，并为下一轮 Sprint 做好准备。它是有效 Scrum 产品待办列表的重要基础。

确定需求

创建 Scrum 产品待办列表始于确定需求。团队须了解用户的业务流程或预期使用场景，获取所需功能等要求，进而分析用户需求。

定义清晰的需求，能够确保待办列表内容符合战略目标，推动成功交付成果。“INVEST”方法，即独立、可协商、有价值、可估算、规模适当、可测试，可用来辅助检查用户故事；它不是每个待办列表条目都必须采用的格式。

需求可以来自不同渠道，例如客户反馈问卷和焦点小组中的客户意见，或 CTO、CEO 等利益相关者对系统关键非功能性能力的指导。有效收集需求的方法包括使用人物画像，或识别关键使用场景，将真实情况带入项目讨论。

获得需求后，Scrum 团队将选择具体的优先级排序技巧，将其排列到产品待办列表中（见下一节）。

优先级排序技巧

如前所述，Scrum 产品待办列表的主要目标之一，是最大限度提升客户价值。因此，为列表中的条目确定优先级尤为重要。可以采用以下技巧，取得更有效的成果：

想象一个装满物品的橱柜：决定某一周可能需要哪些东西，把它们放在前面，较不重要的东西则放到后面。

• MoSCoW 分析： 一种简单模型，将条目分成“必须有”“应该有”“可以有”或“本次不会有”。
• 加权最短作业优先（WSJF）： 这种方法先计算延迟成本，再除以作业规模。
• Kano 分析： Kano 分析根据产品待办列表条目（PBI）对客户满意度的影响，帮助确定优先级。
• 价值与复杂度： 这种技巧将每个 PBI 的感知客户价值，与跨职能团队评估的复杂度对应绘图。

无论采用哪种排序方法，都应尽可能充分协作，必要时让利益相关者和客户参与。

故事与任务的编写

故事编写是迭代过程，目的是从每位利益相关者视角，记录需要完成的事项。格式简单，却足以用容易理解的方式传达所有相关信息。任务编写则侧重确定，各个方面能否在规定时间内完成。

以下是一个用户故事示例：

作为<用户类型>，我想要<某个目标>，以便<原因>。

具体措辞根据团队需求而异，但始终包括谁想要某事、想要什么，以及为什么想要。故事通常从最终用户视角编写，并应包含足够细节，确保所有需求得到满足。

此外，团队确定每个 PBI 的用户故事后，需要将这些大块工作拆成可执行任务。此时就需要任务编写：把各个 PBI 拆解成更小的工作块，进行估算并在一个 Sprint 内完成。

适应与有效管理

敏捷方法强调持续适应和实时管理技巧。在 Scrum 中，这通过产品待办列表实现：它是一处可访问的载体，让产品工作可见、得到排序，并根据市场反馈调整；详细的 Sprint 任务则在 Sprint 待办列表中管理。敏捷实践者可以利用跨职能团队的意见，创建可见的项目待办列表，并持续细化，以满足不断演进的需求。

把它看作产品的一份持续演进的文档：随着您越来越了解客户，它也不断变化、成长。

Scrum 有效管理的一项基本原则是透明，确保每位成员都能访问产品待办列表，理解各条目的优先顺序。这有助于开发团队与利益相关者协调，后者可能在待办列表细化过程中提供宝贵见解。

不过，敏捷项目的成功交付，不仅需要细化一份全面的产品待办列表，还需要参与 Sprint 规划的主要利益相关者协作。这就引出了 Scrum 的另一个重要方面：界定 Sprint 范围。

界定 Sprint 范围

采用敏捷方法的软件开发团队面临一项关键挑战：在紧迫期限内有效管理可能的范围变化。界定 Sprint 范围，是指设定项目边界、识别不同开发阶段的交付成果，并审慎确定整体时间安排的过程。

例如，如果估计交付某项功能需要四周，可以把它拆成两到三个较小功能，在一到两个 Sprint 中完成。这样，团队通过较短的交付节点更好地管理风险，及早发现潜在问题。

界定 Sprint 范围时，应以产品目标所明确的目的为依据，并让关键利益相关者充分参与。界定范围时明确“完成定义”，有助于管理大家对 Sprint 时间内需要交付什么的期望。

成功界定 Sprint 范围，需要理解产品路线图，并掌握如何平衡市场需求与现实时间安排。结果是一种易于管理、可预测的方式，与敏捷方法原则相符。

了解如何界定 Sprint 范围之后，现在来探索成功的敏捷项目如何适应优先级变化。

适应优先级变化

利益相关者在敏捷项目中面临的一大挑战，是适应不断变化的优先级。随着产品演进，新的功能和需求可能出现，打乱 Sprint 中已经制定的计划。这要求持续跟踪项目、预判变化，确保任何优先级调整都不会损害团队实现产品目标的能力。

例如，一个团队正在为在线学习平台开发网站。开发一个月后，他们可能意识到需要增加与其他平台的集成功能。妥善管理下，这项变化可能增强产品功能，但也可能打乱当前规划的工作流程。

这种情况下，应持续收集反馈，利用 Sprint 评审检视产品成果、调整优先级。Sprint 回顾则用于改善团队工作方式。Scrum 团队必须及早预判优先级变化，确保有足够时间开展细化和规划。

对敏捷项目成功的影响

敏捷项目能否成功，往往直接取决于利益相关者管理产品待办列表条目和确定其优先级的有效程度。结构清晰、管理良好的列表，能让利益相关者更了解项目，提高效率，并确保每个 Sprint 的进展具有足够透明度。

正因如此，准确维护高价值 PBI 的相关数据，可以为管理团队提供充足信息，识别同时符合产品目标和公司战略的条目，进而确保稳定的投资回报。此外，维护已排序的待办列表，定期更新需要关注的事项，可以减少利益相关者之间的摩擦，让变化更容易实施。

因此，要通过有效沟通，让敏捷环境中希望按价值决策的人们不受组织层级影响、协调合作，首先需要理解待办列表的重要性。Scrum 框架让组织拥有能够围绕共同目标有效协作的敏捷开发团队。

把待办列表想象成汽车方向盘。发动机（开发团队）固然不可或缺，但还需要有效控制转向，才能沿正确路线行驶。

面向敏捷团队及其利益相关者的产品待办列表问答

Scrum 中谁负责编制产品待办列表？

在 Scrum 中，产品待办列表通常由产品负责人编制和管理。产品负责人还负责根据反馈、需求变化和不断演进的优先级，定期细化并更新列表。开发团队和 Scrum Master 可以提供意见，但产品负责人对列表内容和优先级拥有最终决定权。

Scrum 团队的产品待办列表规模有多大？

Scrum 团队的产品待办列表规模，会因项目复杂性和范围而异。它是一份动态、按优先级排列的列表，包含产品需要处理的功能、改进和修复。规模并不固定，会在开发过程中变化。团队必须主动管理和排序，才能向客户交付最大价值。

Scrum 产品待办列表应多久审视和更新一次？

应在整个 Sprint 中持续审视和更新 Scrum 产品待办列表，让 Sprint 规划开始时，对最重要的后续工作有足够清晰的理解。这确保列表始终反映最新优先级与需求。Agile Alliance 的一项研究显示，更频繁审视和更新产品待办列表的团队，项目成功率和生产力高于较少开展这些工作的团队。因此，持续审视和更新列表，是敏捷项目成功的重要条件。

团队管理 Scrum 产品待办列表时，常遇到哪些挑战？

常见挑战包括优先级安排不当、需求不清，以及利益相关者管理问题。项目管理协会（PMI）的调查显示，38% 的项目经理将需求不明确或不断变化，列为敏捷项目的一项主要挑战。此外，《Journal of Systems and Software》刊登的一项研究发现，利益相关者管理无效可能导致待办列表细化中的冲突与延误。这些挑战会影响团队持续、高效交付价值的能力。

维护良好的 Scrum 产品待办列表有哪些关键组成部分？

关键组成部分包括清晰、已排序的用户故事列表，每个故事详细的验收标准，在有助于决策时进行适当的条目规模估算，以及持续细化以保持列表更新。Scrum Institute 的调查显示，维护整理充分的待办列表的团队，生产力高 22%，按时交付的可能性高 35%。因此，维护这些组成部分对敏捷项目成功至关重要。

Scrum 产品待办列表与传统项目管理待办清单有何不同？

两者有多方面不同。首先，产品待办列表是动态、持续演进的，普通待办清单通常较为静态。其次，产品待办列表根据功能的重要性和紧迫性排序，聚焦向客户交付价值，而普通清单未必以客户为中心。麦肯锡的一项研究显示，有效使用产品待办列表的敏捷项目，其成功可能性比单纯依赖传统项目管理技巧的项目高 28%。因此，采用 Scrum 产品待办列表能够显著提升敏捷项目成功率。

如何有效确定 Scrum 产品待办列表条目的优先级？

可以采用多种策略。一种有效方法是 MoSCoW，将当前版本的条目分为必须有、应该有、可以有和本次不会有。另一种是业务价值排序，根据条目对收入或客户满意度的潜在影响排名。还可以使用 Kano 模型，根据客户偏好和惊喜因素排序。研究显示，这些策略帮助团队更快交付高价值功能，使整体项目成功率提高最多 30%。

敏捷团队中的 Scrum 产品待办列表与产品价值回顾

在采用 Scrum 的敏捷团队中，产品待办列表是由产品负责人整理、按优先级排列的动态工作条目列表。这一 Scrum 框架的关键要素，汇集团队、利益相关者和客户的共同知识。它说明将开展的工作内容与范围，提供透明路线图，支持团队逐步交付价值。通过持续细化和反馈循环，产品待办列表确保团队适应需求变化，并让工作符合客户不断演进的需要。

对于致力于高效交付客户价值的敏捷团队，采用 Scrum 产品待办列表至关重要。 维护按优先级排列的工作条目列表，能让团队专注最有影响的任务，促进协作，最大限度提升生产力。持续学习和适应是敏捷理念的核心，鼓励团队利用 Scrum 框架中的反馈循环。团队使用产品待办列表时，不仅细化信息和工作，也会加深对客户需求的理解，确保敏捷之旅可持续、以价值为导向。

坚持 Scrum 实践，产品待办列表的迭代特性将引导团队持续改进、取得成功。非常感谢您的阅读！