The Scrum Framework — 第二版

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

---

Scrum 用户故事：有效管理 Scrum 用户故事的全面概览

定义：Scrum 用户故事是在敏捷 Scrum 项目中，以用户为中心简洁描述所需功能的一种方式，常用于描述 Scrum 的产品待办列表条目；框架并不强制采用这种格式。用户故事通常从最终用户视角出发，说明具体需求中的谁、做什么，以及为什么，强调跨职能团队之间的协作与沟通。它采用简单模板，包括用户角色（行为者）、期望的行动或目标，以及收益或价值。用户故事帮助各方共同理解项目需求，促进增量推进，并根据用户需求与反馈确定优先级，从而支持敏捷开发。

Scrum 用户故事，就像为软件或产品所需的每项功能编写电影情节，只是更短、更简单。每个故事都有角色（用户或行为者）、目标（所需功能），以及它为何重要（带来的收益）。现在想象这些独立的故事彼此连接，形成由愿望、期望和解决方案交织而成的网络，也就是待办列表。听起来也许出人意料，管理这份列表、确定优先级并加以细化，就像执导一部电影，每个故事都很重要，同时又可以调整。International Scrum Institute 将在您掌握这些 Scrum 用户故事及其有效管理的旅程中，提供贴切的指导。

要在 Scrum 中编写清晰有效的用户故事，可以采用这样的格式：“作为[角色]，我想要[能力]，以便[收益]。”例如：“作为客户，我希望能轻松跟踪订单状态，以便据此安排自己的时间。”

Scrum 用户故事的特点

Scrum 产品待办列表中的条目，常以用户故事的形式编写。Scrum 用户故事最重要的特点，是用一个简短故事描述某人如何使用产品。它包含名称、简短叙述，以及判断故事是否完成的验收标准和条件。用户故事的优势在于，聚焦用户真正需要或想要的东西，而不深入讨论如何实现。

定义用户故事有不同的建议。可以采用以下模板：

作为[行为者]，我[想要|必须][行动]，以便[达成结果]
或使用更简短的版本：
作为[行为者]，我[想要|必须][达成结果]

行为者： 故事描述的是谁的需求，而不是谁对待办列表负责。这通常是用户，但更明确的描述会更有帮助。指定具体行为者，例如“管理员”“已登录客户”“未认证访客”，更容易让人理解，也为用户故事提供了背景。

行动： 行为者想要做什么。如果是强制行动，可以在前面加上“必须”；否则使用“想要”。

达成结果： 行为者希望通过行动达成什么。这是从行为者视角看，执行行动后得到的结果。

Scrum 用户故事概览

在瞬息变化的敏捷项目管理世界中，用户故事是有效传达客户需求的重要工具。它从最终用户视角呈现需求，让原本抽象的项目要求变得鲜活。

用户故事是简洁、非正式的功能描述，编写时明确考虑最终用户（故事中的行为者）的需求，通常采用“作为[用户/行为者]，我想要[功能]，以便[收益]”的结构。这种简单而有力的格式，确保每个故事都说明谁会使用功能、想要什么，以及为什么需要。涵盖“谁”“什么”和“为什么”，让用户故事能够全面、整体地呈现需求。

例如，假设某电商网站的最终用户需要更高效的搜索功能，便于查找产品。相应的用户故事可以写成：“作为买家，我希望有更高效的搜索功能，以便快速找到感兴趣的产品。”这从用户视角简洁地抓住功能本质，并明确其对最终用户的价值。

此外，用户故事还是利益相关者、产品负责人和开发团队深入交谈的起点。它引发关于客户需求的有意义讨论，促进团队成员与利益相关者之间的协作和理解。

除了作为沟通工具，用户故事还在产品待办列表的优先级安排中发挥关键作用。它帮助判断哪些功能对最终用户（行为者）最重要，哪些应优先开发。

用户故事在敏捷项目管理中的作用

理解敏捷项目管理中的用户故事概念，对项目团队大有裨益：它让团队清楚了解客户需求，并专注于真正对最终用户重要的功能，交付出色价值。

这就像建房：没有蓝图，也不了解屋主需求，就不会贸然开工。同样，用户故事为项目奠定基础，让所有人的努力都围绕满足客户期望展开，并在整个项目过程中为开发团队指明方向。

用户故事在敏捷环境中如此重要，组织必须优先帮助团队学习如何编写有效的用户故事。International Scrum Institute 提供全面资源，帮助团队掌握敏捷方法的这一基础环节。这些资源讲解如何编写完善的用户故事，并介绍在产品待办列表中管理故事的最佳实践。

现在您已充分理解用户故事在敏捷项目管理中的重要性，下一节让我们探索如何编写有效且有影响力的用户故事。

有效编写 Scrum 用户故事

用户故事是敏捷开发流程的核心，有效编写用户故事是任何项目成功的关键。以下是编写有效 Scrum 用户故事时应牢记的重要原则。

理解用户需求

理解最终用户的痛点和需求，是编写有影响力的用户故事的首要步骤。花时间站在用户立场思考，深入了解他们的体验、愿望与挑战，能够确保故事真正解决实际用户需求，交付切实价值。问卷、访谈或观察研究等方法，可以直接从最终用户那里获取见解。

组织故事结构

SMART 是讨论故事预期成果的一种有用视角，并非 Scrum 强制要求的模板：

• 具体（Specific）—— 明确需要完成什么
• 可衡量（Measurable）—— 明确如何衡量成功
• 可实现（Achievable）—— 确保在给定约束下切实可行
• 相关（Relevant）—— 符合业务目标和用户需求
• 有时限（Time-bound）—— 设定清晰的交付时间表

这为开发团队提供清晰框架，确保每个故事都直接有助于实现项目目标，并为最终用户交付实际价值。

让团队参与

让整个团队参与故事编写，可以促进协作，确保大家共同理解需求和最终目标。开发人员、设计师、测试人员及产品负责人等不同角色的视角，能够全面呈现需要达成的结果。这种协作方式有助于及早发现宝贵见解和潜在挑战，形成更完善、更能代表团队共同愿景的用户故事。

理解最终用户、有效组织故事结构，并让整个团队参与编写，这些都至关重要。掌握了这一点，我们便具备了编写有吸引力、有影响力的 Scrum 用户故事的基本原则。

有了用户故事编写原则的坚实基础，现在来探索如何确定这些故事的优先级，使其对敏捷项目发挥最大作用。

用户故事优先级排序技巧

随着产品待办列表不断增长，有效确定用户故事的优先级变得必不可少。毕竟，各项功能的重要性并不相同，有些对客户满意度或产品开发的影响更大。以下两种实用技巧可以帮助您作出明智决定，最大限度提升敏捷团队交付的价值。

MoSCoW 方法

MoSCoW 优先级排序法将用户故事分为四个重要类别：必须有、应该有、可以有，以及本次不会有。这种方法简单有效，帮助团队根据紧迫性和重要性，识别开发中的关键功能。

• 必须有： 这些是不可妥协的功能，对于产品基本运行或满足用户根本需求不可或缺。缺少它们，产品的主要用途就会受到影响。
• 应该有： 这些功能很重要，但并非首次发布不可或缺。它们有助于产品完整，必要时可以推迟。
• 可以有： 这些功能值得拥有，但属于可选项，能够改善用户体验或增加价值。推迟到以后完成，也不会影响产品核心功能。
• 本次不会有： 目前认为不需要的功能，会有意识地排除在本次工作范围之外。

MoSCoW 方法提供清晰分类，帮助利益相关者与敏捷团队对齐期望，并就应先开发什么达成共识。

Kano 模型

除了 MoSCoW，还可以考虑 Kano 模型，按用户故事对客户满意度的影响进行分类。Kano 模型区分三类客户需求属性：基本型、期望型和兴奋型。

• 基本型属性： 这些是客户预期具备、常常认为理所当然的基本要求。满足时不一定增加满意度，但缺少时可能导致不满。
• 期望型属性： 这些属性与客户满意度直接相关：表现越好，满意度越高。不过，也存在收益递减；过度提升期望型属性，并不总会让客户更加惊喜。
• 兴奋型属性： 这些属性在具备时可能让客户惊喜、愉悦，缺少时却不会严重影响满意度。

识别每个用户故事所属的类别，能够让产品负责人更深入了解用户优先需求，从而就功能开发作出符合客户需要和愿望的明智决定。

采用这些优先级排序技巧，可以确保敏捷团队通过真正重要的功能交付价值，避免在非关键要素上浪费精力，同时提升整体客户满意度。

了解有效的用户故事优先级排序技巧后，现在转向利益相关者在塑造和细化这些故事中的关键作用。

利益相关者在 Scrum 用户故事中的作用

在 Scrum 世界里，利益相关者就像指路的星辰。他们清楚用户想要什么、业务需要什么。他们的意见对于编写真正反映用户与业务需求和期望的故事至关重要。缺少他们参与，就像没有地图开车，方向不明，很可能迷路。

例如，假设正在开发一款新的手机银行应用。利益相关者来自市场营销、客户服务、IT 安全和多个技术部门。每个人都带来独特视角，共同全面呈现应用需要实现什么。营销部门可能强调直观且有吸引力的界面，客服可能优先考虑顺畅的交互功能，而 IT 安全则关注可靠的安全协议。

正如养育孩子需要众人支持，成功让用户故事落地，也需要这些不同视角共同贡献意见。

让利益相关者参与用户故事细化，有以下几方面帮助：

• 贴合现实： 他们提供真实场景与用户需求方面的见解，确保用户故事符合实际业务要求。
• 反馈循环： 通过积极邀请利益相关者参与，团队能够在流程各阶段收集反馈，推动迭代改进。
• 与业务目标一致： 利益相关者帮助确保用户故事与更大的业务目标相连，支持更具战略性的决策。

例如，如果利益相关者没有参与塑造手机银行应用的用户故事，就可能开发出不符合客户期望或不满足监管标准的功能，导致后续延误，甚至代价高昂的返工。

此外，从一开始就让利益相关者参与，既能形成主人翁意识和责任感，也能营造协作与沟通蓬勃发展的环境。

现在已经清楚，利益相关者参与 Scrum 用户故事细化为何如此关键。他们的见解与指导引导故事朝着实现业务目标、有效满足用户需求的方向前进。

了解利益相关者在塑造 Scrum 用户故事中不可或缺的作用后，现在来探索如何估算复杂度，以有效管理 Scrum。（更多内容请参阅 Scrum 投入估算)

通过复杂度估算有效管理 Scrum

估算用户故事的规模，能帮助团队理解其工作量和复杂度。估算用于支持决策，并非保证；Scrum 也不规定某一种估算技巧。Scrum 中常用的方法之一是规划扑克，它使用一副带数字的卡牌，表示不同的工作量或复杂度水平。

团队成员讨论一个用户故事，然后各自选择代表自己估算值的卡牌。大家同时亮牌，并讨论估算中的显著差异。重复这一过程，直到对故事复杂度达成共识。

这样，每个人的意见都得到考虑，鼓励所有成员积极参与。共同估算帮助团队更好地理解彼此视角，甚至可能发现故事中此前未被注意到的复杂因素或挑战。

例如，有个用户故事是为应用创建登录页面。一位成员可能认为很简单，给出 3；另一位考虑到所需的各种验证规则，给出 8。公开讨论这些差异，能让团队更深入地理解任务，并可能发现此前未考虑的组成部分。

规划扑克得出的工作量估算，不仅有助于 Sprint 规划，也有助于资源分配和理解团队容量。在 Sprint 规划中，产品负责人使用这些估算，根据复杂度和潜在交付价值，为用户故事确定优先级。

这些估算对判断一个 Sprint 实际能承担多少工作至关重要，确保团队不会过度承诺，陷入过劳或质量问题。它也能帮助识别用户故事之间的依赖关系，改善工作顺序和依赖管理。

通过规划扑克等技巧有效估算复杂度，是 Scrum 项目管理保持透明、促进协作和明智决策的基础。

清楚了解复杂度估算如何影响 Scrum 项目管理后，现在来看如何利用 Scrum 用户故事有效管理产品待办列表。

使用 Scrum 用户故事管理产品待办列表

用户故事代表客户的声音，引导开发团队创建符合最终用户需求的产品。它提供有价值的背景，确保开发团队理解期望，以及产品将给最终用户带来的价值。有效使用用户故事，能通过全面呈现客户需求，使沟通更清晰、决策更顺畅；这对于维护组织有序、持续细化的产品待办列表不可或缺。

实践中，让客户、最终用户、产品负责人和开发人员等多方利益相关者参与编写用户故事很有帮助。不同视角确保故事涵盖多样需求和使用场景，更全面地呈现产品功能。

例如，在银行应用的软件开发项目中，用户故事可以描述客户希望在账户之间顺畅转账的需求。这帮助开发团队理解具体功能要求，以及对用户体验的潜在影响。

此外，用户故事具有动态性，可以根据不断变化的客户需求和市场趋势持续细化、重新排序。定期更新并重新评估故事，能让产品待办列表保持敏捷，适应业务需求变化。

每个用户故事都必须清晰、具体地说明其代表的功能。结构良好的用户故事通常采用以下格式：“作为（角色），我想要（功能），以便（收益）。”

此外，在每个用户故事中加入验收标准，能够补充细节，明确功能被视为完成时必须满足的条件。这些标准客观衡量功能何时实现预期用途，让开发团队和利益相关者对预期成果保持一致。

在银行应用的例子中，一项验收标准可以规定：账户间转账时，系统应验证账户凭证，并及时生成交易回执。这确保所有利益相关者共同理解，该用户故事怎样才算成功实现。

有效运用用户故事，能让产品负责人清楚梳理客户需求，让开发团队设计符合最终用户需要的解决方案。随着业务环境变化持续细化故事，组织可以维护灵活的产品待办列表，随时应对动态市场需求。

运用 Scrum 用户故事的灵活性，组织能够确保产品待办列表始终响应不断变化的客户需求和市场动态。这种适应能力，是交付真正契合最终用户需求的产品的关键。

Scrum 用户故事有哪些关键组成部分？

回答：Scrum 用户故事的关键组成部分包括角色或人物画像、对所需功能的简短描述，以及验收标准。这些部分帮助理解最终用户视角，并为开发提供明确指引。Stack Overflow 在 2023 年的一项调查中，87% 的敏捷团队强调，定义清晰的用户故事对有效管理待办列表十分重要。

用户故事如何帮助 Scrum 的 Sprint 规划和优先级排序？

回答：用户故事清晰呈现用户视角、需求和期望成果，帮助 Scrum 的 Sprint 规划与优先级排序。它让开发团队围绕用户目标开展工作，并根据价值和复杂度判断应先处理哪些故事。VersionOne 在 2022 年开展的调查显示，在 Sprint 规划中有效确定用户故事优先级的团队，生产力和客户满意度都会提高。

Scrum 方法中用户故事的目的是什么？

回答：Scrum 方法中用户故事的目的是记录最终用户或客户的要求与需求。它作为开发团队与利益相关者之间的沟通工具，促进理解和协作。用户故事聚焦向客户交付价值，并帮助根据用户反馈和业务价值，确定待办列表条目的优先级。Scrum Alliance 的一项调查显示，76% 的受访者认同用户故事改善了团队交付客户价值的能力。

如何为敏捷开发编写有效的用户故事？

回答：为敏捷开发编写有效用户故事，应关注“三个 C”：Card（卡片，简短描述）、Conversation（交谈，讨论细节）和 Confirmation（确认，验收标准）。故事应简洁、具体，并根据客户价值排序。VersionOne 的一项调查显示，65% 的敏捷团队认为，保持故事规模小、定义清楚有助于项目成功。开发人员、产品负责人与客户定期协作，也对共同理解需求、保持一致至关重要。

在 Scrum 中使用用户故事，有哪些最佳实践或常见误区？

回答：有几项最佳实践和常见误区值得注意。最佳实践包括：清楚定义每个故事的角色、目标和收益；根据价值和复杂度排序；让整个团队参与编写和估算；定期细化并更新待办列表。常见误区包括：故事细节过多或过于技术化；未让利益相关者参与编写；忽视将大型故事拆分成小故事；未定期更新或整理待办列表。Scrum Alliance 的一项调查显示，遵循这些最佳实践的团队报告了沟通改善（74% 的受访者）、与业务目标更加一致（68% 的受访者），以及客户满意度提高（62% 的受访者）。

Scrum 用户故事回顾

Scrum 用户故事的一个关键方面，是细致地梳理需求映射关系，每个故事都是迭代开发过程中有价值的一部分。用户故事常被视为史诗的组成单元，清楚说明开发团队要处理的重要事项，促进整个迭代成功。识别由多个用户故事组成的史诗，有助于全面规划和执行项目。本文探讨了在敏捷方法中使用用户故事的好处，说明其如何改善公司内部沟通，并让有价值的信息更顺畅地传递。

理解用户故事的重要性，也要认识它为开发团队和最终用户带来实际收益的作用。本文的具体例子说明，用户故事如何支持有效的测试策略，确保每项交付成果都符合规定标准。通过将复杂功能拆成易于管理的部分，用户故事帮助公司更从容地推进迭代开发。这既促进协作，也支持在每轮迭代中随着项目需求变化灵活调整。

用户故事是敏捷框架中的关键要素，为项目管理提供结构化方法。无论是将史诗拆成可管理的部分、支持高效的迭代规划，还是改善公司内部沟通，用户故事都对成功交付成果至关重要。 正如各种例子和测试策略讨论所示，用户故事确保每项交付成果符合整体目标，为开发过程增加价值。对于希望加深敏捷方法理解的人，International Scrum Institute 提供注册 Scrum 认证的宝贵机会，进一步帮助个人凭借专业知识和信心，应对不断变化的项目管理环境。