产品待办事项构建（PBB）画布：如何编写高质量用户故事

产品待办事项构建画布，也常被称为 PBB 画布，是一种帮助团队梳理产品待办事项列表、拆解功能并编写用户故事的方法。它特别适用于敏捷团队在产品规划、需求细化和迭代准备过程中，系统化地识别用户、功能、PBI 和验收标准。

许多软件团队会用产品待办事项列表来描述产品需要实现的功能。这个列表通常由一组用户故事组成。每个用户故事都会说明：谁需要这项能力、需要完成什么事，以及为什么需要它。

很多团队习惯认为，产品负责人是产品待办事项列表的唯一来源。但事实上，任何人都可以，也应该参与编写用户故事。

产品待办事项构建画布提供了一套简单的流程，帮助团队完成这项工作。它从描述产品用户及其活动开始。用户活动会进一步衍生出功能，也就是用户与产品之间的交互。随后，功能会被拆解为产品待办事项。最后，团队可以结合用户角色和活动背景，将这些待办事项转化为用户故事。

“用户故事”这一概念最早由 Kent Beck 在极限编程中提出，其目的在于推动一种更加敏捷、更加重视对话的需求收集方式。几年后，Mike Cohn 出版了《用户故事应用：敏捷软件开发》，这本书后来成为该领域的重要参考。

在敏捷方法的早期，团队中的每个人都会编写用户故事，用来沟通需要完成的工作。后来，随着 Scrum 等方法在更多团队中推广，产品负责人逐渐成为编写用户故事并维护产品待办事项列表的主要角色。不过，用户故事并不应该只由产品负责人编写。团队中的任何人都可以，也应该参与其中。

我和 Fábio Aguiar 合著过一本关于产品待办事项构建技巧的书，目的正是帮助团队中的每个人都能写出更好的用户故事。

什么是好的用户故事？

在介绍 PBB 画布之前，我们有必要先了解：什么样的用户故事才算是好的用户故事。下面将介绍几种常用的判断方法和写作原则。

用户故事的 3W

用户故事是一种简洁描述需求的文本格式。它通常需要回答三个问题，也就是 3W：

• Who：这个故事是为谁准备的？
• What：这个人想完成什么动作或活动？
• Why：这个人为什么需要它？它带来了什么好处或价值？

换句话说，一个好的用户故事应该说清楚：谁要做什么，以及为什么要做。

INVEST 原则：判断用户故事质量的方法

William C. Wake 在《极限编程探索》中提出了 INVEST 原则。INVEST 是一个缩写，每个字母分别代表用户故事应具备的一项重要特征：

• Independent，独立：一个用户故事不应强依赖另一个用户故事。
• Negotiable，可协商：用户故事描述的是需求的核心，而不是一份固定不变的合同。它应该为后续沟通和协商留下空间。
• Valuable，有价值：用户故事应清晰体现它为客户或用户带来的价值。
• Estimable，可估算：用户故事应包含足够的信息，使开发团队能够对其工作量进行估算。
• Small，小而合适：用户故事的规模应相对较小，能够在较短时间内完成，并适合放入一个迭代或冲刺中。
• Testable，可测试：用户故事必须足够清晰，以便团队能够为它定义测试用例。

后来，Mike Cohn 将其中的 S 从 Small 调整为 Sized Appropriately，也就是“大小合适”。这是因为在不同团队和不同上下文中，用户故事的粒度可能并不完全相同。只要它适合团队当前的工作方式和交付节奏，就是合适的。

3C 模型：卡片、对话和确认

3C 模型从三个方面描述用户故事：卡片、对话和确认。

Card：卡片

用户故事的描述应当足够简洁，能够写在一张索引卡片上。卡片上只需要记录足以识别这个用户故事的信息，而不需要写下所有细节。

最常见的用户故事格式是：

作为「某个角色 / 用户画像」，
我想要「完成某个动作 / 活动」，
以便「获得某种好处 / 达成某个目标」。

例如：

作为一名参与者，
我想报名参加活动。

这个例子虽然简短，但已经说明了谁需要它，以及这个人想要做什么。

Conversation：对话

用户故事之所以要写得简洁，是因为它不应该取代沟通。索引卡片空间有限，文字描述必须保持简短，因此团队需要通过持续对话来澄清问题、补充细节，并明确实现这个故事所需的工作。

采用用户故事，意味着团队接受这样一种工作方式：关于需求和交付的对话会持续发生，而不是只在一开始确定需求时才发生。

好的文档不是用来替代对话的，而是帮助人们记住已经达成的共识和讨论过的内容。

Confirmation：确认

确认是指团队需要判断用户故事的目标是否已经实现。验收标准正是用来完成这件事的。

验收标准用于确认用户故事是否被正确实现，并且是否成功交付。团队应在开始实现每个用户故事之前，先定义清楚验收标准。这样，在检查完成情况和验证交付结果时，团队就不会产生不必要的分歧。

如何使用 PBB 画布编写用户故事？

如前所述，编写用户故事本质上是在回答三个问题：谁？什么？为什么？

“谁”对应用户角色或用户画像。
“什么”对应用户想要完成的动作或活动。
“为什么”对应这个动作或活动带来的价值、好处或理由。

在《产品待办事项构建》一书中，我和 Fábio 介绍了如何借助 PBB 画布识别用户画像、功能和工作项，并由此构建出高质量的用户故事。

本文将通过一个数字产品示例，说明如何填写 PBB 画布并编写用户故事。这个示例产品名为“演讲合集”，它由海外某区域敏捷实践者群体创建，用于整理演讲内容并组织活动。

图 1：PBB 画布

接下来，我们会介绍 PBB 画布中的三个关键模块：用户画像、功能和产品待办事项。为了便于说明，文中会使用“演讲合集”中的部分用户画像和功能作为示例。

第一步：描述用户画像

用户画像代表产品的真实用户。因此，对用户画像的描述不能只停留在“这个人是什么角色”上，还需要包含他们的需求、目标和行为特征。

这样做可以让用户形象更加具体，也能帮助团队从用户视角出发，描述产品应该具备哪些功能。

图 2：角色模块示例

在描述主要用户画像时，可以思考以下问题：

• 这个人的基本画像是什么？
• 这个人通常会做什么？
• 这个人有什么期待？
• 这个人的目标是什么？

如今，很多团队会通过探索性工作坊、启动研讨会或其他协作活动来梳理用户画像。这些活动通常会产出一些相关材料，例如同理心地图、用户旅程或访谈记录。

如果团队已经有这些材料，就可以在 PBB 过程中加以利用。不过需要注意的是，在 PBB 阶段，重点并不是重新做一遍完整的用户研究，而是提炼出用户画像及其关键活动，因为这些内容会成为后续识别功能和拆解待办事项的基础。

第二步：识别产品功能

在充分理解用户画像及其活动之后，接下来需要分析每个用户画像，重新阅读相关描述，并找出用户与产品之间的互动或行为。每一次重要互动，都可以被表达为一个功能。

图 3：从用户画像到功能

在描述产品功能时，可以使用以下问题来引导思考：

用户想完成某项任务，因此产品必须具备相应能力。这个能力是什么？
这个功能解决了哪些用户问题？
它能为用户带来什么好处？

图 4：特征块示例

团队可以将功能描述写在较大的便签纸上，再把这个功能面临的挑战和带来的好处写在较小的便签纸上，并贴在功能便签旁边。

功能通常比具体开发工作项更高层。也就是说，在真正开始开发某个功能之前，团队还需要进一步分析这个功能，并将它拆解为更具体、可执行、可估算的工作项。

在产品待办事项构建画布中，团队首先要识别功能、理解功能，并确定功能的优先级。之后，再将功能进一步拆解为产品待办事项。

第三步：确定产品待办事项 PBI

产品待办事项，即 Product Backlog Item，简称 PBI，是构成产品待办事项列表的基本元素。它们代表为了改进产品、满足客户或利益相关者需求而需要完成的开发工作。

在上一步中，团队已经描述了产品功能，以及该功能面临的挑战和带来的好处。接下来，需要把这些功能进一步拆分，形成更小、更明确的待办事项。这些待办事项就是 PBI。

为了确定某个功能下的 PBI，可以让参与者依次回答：

这个功能的第一个工作项或步骤是什么？
第二个是什么？
接下来还需要做什么？

图 5：产品待办事项块示例

每个 PBI 都应代表用户在产品中执行的一个动作。例如：

购买图书。
为会议添加演讲者。

这些动作需要用清晰的文字描述，以提供上下文，并让每个待办事项都能够被准确识别。

第四步：将 PBI 转化为用户故事

PBI 是用户故事列表的基础。团队可以结合每个 PBI 所关联的用户画像和功能价值，填充典型的用户故事模板。

图 6：使用 PBB 编写用户故事

在用户故事的“作为谁”部分，填写用户画像。用户画像信息通常写在便签纸上，并贴在 PBB 画布的“用户画像”模块中。例如，用户画像可以是“演讲者”。

在用户故事的“我想要”部分，填写 PBB 画布“产品待办事项”模块中的内容，也就是具体动作。它代表实现某个功能所需的一个步骤。例如，这个动作可以是“发布演讲”。

在用户故事的“以便”部分，填写功能旁边便签中记录的某个好处。它代表该功能带来的价值之一，例如“让内容可被访问”。

因此，一个完整的用户故事可以写成：

作为一名演讲者，
我想发布演讲，
以便让内容可被访问。

写完用户故事的核心内容后，团队还需要补充验收标准、任务、用户界面说明以及赋能项等信息。这些内容可以记录在 PBB 画布的“产品待办事项”区域中，也可以记录在团队日常使用的需求或项目管理工具中。例如，研发团队可以使用 PingCode 将目标、客户反馈、需求清理、评审排期、开发、测试、发布和 Wiki 知识沉淀串联起来，让产品待办事项从规划到交付的过程更加数据化和可追踪；如果团队更偏通用项目协作，也可以使用 Worktile 管理任务、项目、文档、日历、甘特图、工时和审批等协作事项。

PBB 画布中的用户故事示例

下面以“演讲合集”这个数字产品为例，展示三个功能及其对应的用户画像和用户故事。

用户画像：演讲者

功能 1：发布演讲

• 故事 1.1：作为一名演讲者，我需要访问一个工作空间，以便私下管理演讲内容。
• 故事 1.2：作为一名演讲者，我想发布演讲，以便让更多人接触到这些内容。
• 故事 1.3：作为一名演讲者，我想将外部演示文稿与内部演讲关联起来，以便更好地整合演讲内容。

用户画像：参与者

功能 2：参与活动

• 故事 2.1：作为一名参与者，我想查找可参加的活动，以便查看活动日程。
• 故事 2.2：作为一名参与者，我想报名参加活动。
• 故事 2.3：作为一名参与者，我想在活动现场签到，以便确认出席。

用户画像：组织者

功能 3：组织活动

• 故事 3.1：作为一名组织者，我想确定活动日程，以便公布议程安排。
• 故事 3.2：作为一名组织者，我想通过媒体宣传活动，以便吸引观众。
• 故事 3.3：作为一名组织者，我想邀请共同组织者，以便共同推进活动筹备工作。

用户故事还需要补充哪些细节？

前面的模板构成了用户故事的核心，但一个真正可执行的用户故事通常还需要记录更多信息。

虽然 PBB 画布本身并不专门承载所有细节，但对这些内容进行说明依然很有价值。团队可以将这些细节补充到画布中的 PBI 上，也可以使用其他工具来跟踪和维护用户故事。

常见的补充信息包括：

• 验收标准；
• 实现任务；
• 用户界面说明；
• 赋能项。

验收标准

验收标准用于描述如何验证用户故事。它是一份检查清单，用来判断用户故事何时算完成，以及交付结果是否有效。

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

作为一名账户持有人，
我想在 ATM 机上取款，
以便不用在银行排队。

针对这个故事，可以定义如下验收标准：

• 当账户余额充足时，账户持有人可以从账户中取款。
• 当账户余额不足时，账户持有人无法从账户中取款。
• 即使账户余额充足，如果 ATM 机现金不足，账户持有人也无法取款。

这些验收标准可以帮助团队验证故事是否完整、是否有效，以及实现结果是否满足预期。

将用户故事拆分为任务

用户故事通常还会被进一步拆分成更小的任务。任务用于描述为了完成这个用户故事，团队需要做哪些具体工作。

通过列出实现用户故事所需的任务，开发团队可以进一步讨论技术实现细节，并明确每项工作的责任和范围。

与用户故事不同，任务没有固定的文本格式。它们通常更加直接，也更偏技术化，主要用于开发团队内部沟通。

任务代表需要完成的具体工作，是实现用户故事不可缺少的一部分。但任务本身不一定完整独立，也不一定直接体现业务价值。

例如：

• 修改输入表单字段；
• 创建用户测试账户；
• 编写自动化数据生成脚本；
• 调整接口参数；
• 修改数据库字段。

这些都可以是任务。

用户界面

并不是每个工作项都与界面相关。但如果某个工作项涉及用户界面，团队就需要在用户故事的上下文中明确界面要求。

界面可以通过多种方式描述，例如：

• 草图；
• 线框图；
• 视觉稿；
• 可交互原型。

具体采用哪种方式，取决于团队文化、产品复杂度以及团队愿意在前期投入多少时间。

由此会产生一个问题：在开始开发用户故事之前，界面需要被定义到什么程度？

答案取决于团队共识。也就是说，团队需要共同判断：从用户界面的角度来看，这个用户故事是否已经准备好进入开发。

最重要的是，团队要对目标形成一致理解，并且对即将开展的工作有足够信心。

赋能项

有时候，一个工作项很难被写成好的用户故事。即使你已经尝试使用 INVEST 和 3W 作为指导，仍然可能无法写出令人满意的结果。

如果出现这种情况，可以判断它是否属于以下两类情况之一：

• 这个工作依赖某些前期研究；
• 这个工作依赖某些专业技术知识，并且需要投入较多精力。

如果属于上述情况，团队可以把它视为某个更大故事的一部分，也可以把它拆分成一个独立条目：赋能项。

赋能项之所以叫赋能项，是因为它通常不遵循用户故事格式。它本身未必直接交付用户价值，但它是实现某个用户故事或某组用户故事的必要前提。

探索性赋能项

例如：

作为一名开发者，
我想研究异步消息传递的工作原理，
以便决定如何实现聊天功能。

严格来说，这并不是一个真正的用户故事，也没有必要把它写成用户故事格式。它更适合作为一个探索性赋能项。

它需要在相关用户故事之前完成。例如，相关用户故事可能是：

作为一名参会者，
我想在活动聊天中发送消息，
以便与其他参会者互动。

这个例子说明，在着手实现用户故事之前，团队可能需要先完成一个探索性步骤：研究异步消息传递的工作原理。

探索性赋能项通常包括：

• 技术调研；
• 背景调查；
• 问题澄清；
• 方案比较；
• 技术选型。

它们的作用是为后续高效实现用户故事奠定基础。

Spike 是探索性赋能项的常用说法。

技术赋能项

非功能性需求、重构、流水线改进、测试基础设施改进等工作，有时需要投入大量精力，不适合直接放入某个用户故事中。

在这种情况下，团队可以将它们描述为技术赋能项。

同时，团队也需要说明哪些用户故事依赖这些赋能项。这样可以避免赋能项脱离业务目标，变成孤立的技术工作。

需要注意的是，团队不应过度使用赋能项。否则，产品待办事项列表最终可能会变成一组技术任务，而不再体现清晰的用户价值。

技术赋能项不需要写成用户故事格式。与其写成：

作为一名开发人员，
我想迁移自动化测试套件，
以便提高性能。

不如使用更直接的表达：

执行自动化测试迁移。

这样的写法更清楚，也更符合技术赋能项的特点。

完整用户故事示例：发布演讲

现在，我们来看“演讲合集”中“发布演讲”功能下的一个用户故事示例。这个示例包含完整的用户故事、验收标准、任务、用户界面说明以及赋能项。

用户故事 1.1

作为一名演讲者，
我想将外部演示文稿与演讲内容关联起来，
以便更好地整合演讲资料。

验收标准 1

场景 1：关联演示文稿分享平台上的演示文稿

假设海外某演示文稿分享平台上存在一个有效链接，
当我关联外部演示文稿链接时，
那么屏幕上会显示该演示文稿的预览。

验收标准 2

场景 2：发布演讲时关联演示文稿

假设演示文稿链接有效，
当我发布演讲时，
那么已发布的演讲详情中会显示相关演示文稿。

任务

• 使用演示文稿端点。
• 创建用于显示演示文稿 PDF 文件的用户界面。
• 在后端创建逻辑，将演示文稿与已发布的演讲关联起来。
• 将参数调整为公共链接或私有链接。
• 创建测试数据，以验证链接是否有效。
• 修改数据库，使其能够存储演示文稿链接。

界面草图

探索性赋能项

研究端点 API 与海外某些在线演示文稿分享平台的集成方式。

技术赋能项

使用 oEmbed 端点作为响应头中的链接标签，以便在嵌入演示文稿时能够被自动检测。

DoR 与 DoD：定义“准备就绪”和“完成”

在管理产品待办事项时，团队通常还需要明确两个重要概念：准备就绪的定义和完成的定义。

它们可以帮助团队判断：一个 PBI 是否已经可以进入开发，以及一个 PBI 是否真正完成。

准备就绪的定义 DoR

准备就绪的定义，即 Definition of Ready，简称 DoR，是团队达成的一项共识，用来说明一个产品待办事项何时可以进入迭代周期。

换句话说，DoR 用于判断某个 PBI 是否已经具备足够信息，可以进入计划、执行和交付阶段。

当人们说“这个事项可以开始做了”时，通常意味着团队已经确认：

• 团队具备处理该事项所需的信息；
• 团队理解该事项的目标和用途；
• 团队知道如何证明该事项已经完成；
• 团队清楚该事项如何构成某个功能，或与某个功能相关；
• 团队认为该事项适合在一个冲刺或指定时间范围内完成。

针对下一个迭代或工作周期中的每个候选 PBI，团队都可以使用类似下面的检查清单进行确认。

PBI 准备就绪检查清单

• PBI 已以用户故事的形式呈现。
• PBI 已具备验收标准。
• 已识别需要改进或创建的 PBI 验收测试。
• PBI 已具备必要的用户体验要素。
• 已识别 PBI 的依赖项，如有。

这是一份 DoR 检查清单示例。不同团队通常会制定并维护自己的检查清单，以体现他们对准备工作的标准和偏好。

产品待办事项列表的细化应当持续进行。团队需要不断推进下一批候选条目的准备工作，为下一个迭代或工作周期做好准备。

准备就绪的定义和完成的定义并非 Scrum 独有。在看板以及其他敏捷方法中，它们同样非常有用。

完成的定义 DoD

完成的定义，即 Definition of Done，简称 DoD，是团队用来确认 PBI 质量的一项约定。

这里的“完成”并不只是指代码写完了，而是指团队已经认可该项工作的交付质量和完成状态。

DoD 明确了产品增量中“已完成工作”的标准。一旦某个 PBI 符合完成的定义，就意味着该产品增量已经准备好发布到产品中。

如果某个 PBI 不符合 DoD，就不应该发布，也不应该在迭代评审中作为已完成内容进行展示。它应继续作为团队的在制品，也就是 WIP，继续处理。

对于每个被认为已经完成的 PBI，团队需要证明它满足以下条件：

• 已交付产品增量；
• 已符合既定验收标准；
• 已编写必要的使用说明；
• 已符合编码标准；
• 已维护产品性能指标。

PBI 完成检查清单

• 已交付产品增量。
• 已满足验收标准。
• 已完成必要的使用说明。
• 已符合编码标准。
• 已维护产品性能指标。

这是一份 DoD 检查清单示例。不同团队通常会制定并维护自己的清单，以体现他们对工作验证和质量标准的偏好。

总结：用 PBB 画布提升用户故事质量

产品待办事项构建画布能够帮助团队从用户画像出发，识别产品功能，拆解产品待办事项，并最终形成清晰、可讨论、可验证的用户故事。

对于希望提升产品待办事项列表质量的敏捷团队来说，PBB 画布不仅是一种需求梳理工具，也是一种促进团队协作和共识形成的方法。通过结合用户故事、PBI、验收标准、DoR 和 DoD，团队可以让产品规划和迭代交付更加清晰、高效。