含验收标准的用户故事模板（免费）

用户故事模板承担两项任务。它确保每个故事都回答相同的三个问题（谁、什么、为什么），并为团队提供一个固定的位置来记录如何判断故事已完成。本页为您提供这两者：单行故事格式、可复制的完整卡片模板、三种格式的验收标准、就绪与完成的定义，以及实际示例。

如果您是用户故事的新手，请先阅读我们的指南 如何编写用户故事，然后回到这里查看模板。

单行用户故事模板

大多数团队使用源自 2001 年伦敦 Connextra 团队、并由 Mike Cohn 的著作《User Stories Applied》（他对用户故事的概述 是一个很好的入门介绍）推广的格式：

作为一个[用户类型]，我想要[一个动作或能力]，以便[一个收益或结果]。

每个部分都有特定的作用：

• “作为一个”指明一种真实用户类型，例如首次购买者、账户管理员或回访患者。“作为一个用户”对团队没有任何信息量。如果您有人设，请使用人设名称。
• “我想要”描述用户做什么或获得什么，使用用户的语言。它不应描述解决方案（如“下拉菜单”、“Redis 缓存”）；应留给团队空间去寻找最佳方案。
• “以便”陈述价值。这是最常被跳过但最重要的一部分：它使团队能够提出更简单的选项以实现相同结果，并帮助产品负责人决定优先级。

请记住，句子本身不是需求。Ron Jeffries 将故事描述为三件事：卡片、对话和确认（3C原则）。模板有助于卡片和确认（验收标准）；但没有什么能取代对话。

完整用户故事卡片模板

单行描述足以写在便利贴上。在待办事项工具中，您通常需要更多字段，以便对故事进行排序、估算和测试。以下是我们认为有用的字段；您可以删除团队从不查看的任何字段。

保持“上下文与备注”简短：如果它变成了一页规格说明，那么该故事很可能是一个史诗（Epic），需要拆分（参见我们的 故事映射指南 展示了如何操作）。

可直接复制的用户故事模板

将此内容粘贴到 Jira 或 Linear 问题的描述字段、Notion 数据库模板或电子表格的表头行中。替换方括号内的文本，并删除您不使用的行。

• ID：[PROJECT-000]
• 标题：[动词 + 宾语，例如“将发票导出为 CSV”]
• 故事：作为一个[用户类型]，我想要[动作或能力]，以便[收益]。
• 上下文：[为何现在重要；链接到研究、支持工单或指标]
• 验收标准：[3 到 7 个可测试的条件，以清单或 Given/When/Then 形式呈现]
• 范围之外：[本故事故意不涵盖的内容]
• 设计稿：[链接到框架或原型]
• 依赖项：[其他故事、服务或决策]
• 优先级：[必须/应该/可以，或待办事项列表排名]
• 估算：[点数或规模，由团队填写]
• 待解决问题：[冲刺开始前必须回答的任何事项]

“范围之外”这一行可以避免争论：在卡片上写明“不包括短信重置”比在冲刺回顾中发现有人假设包含它要好得多。

验收标准是什么，以及由谁编写

验收标准是故事必须满足才能被产品负责人接受的条件。它们从用户角度描述可观察的行为，而非代码如何工作。好的标准是：

• 可测试：有人可以不加解释地说出“是”或“否”。“快”不可测试；“结果在两秒内出现”则可测试。
• 针对本故事特定：适用于每个故事的规则（代码审查、部署到预发布环境）属于完成定义，而非此处。
• 无实现细节：说明发生了什么，而非哪个组件或表使其发生。
• 对失败诚实：至少一个标准涵盖无效输入、无网络或缺少权限的情况。
• 数量少：三到七个标准是健康范围。超过十个通常意味着故事应被拆分。

产品负责人对标准负责，但不应独自编写。最可靠的模式是产品、开发人员和测试人员之间简短的细化对话（常称为“三友”）：价值是什么，将如何构建，可能如何出错。

格式 1：清单式验收标准

一个条件列表。这是最快编写和阅读的格式，适用于简单故事和手动测试的团队。

故事：作为一个回访客户，我想要通过电子邮件重置密码，以便我无需联系支持团队即可重新进入账户。

• 登录屏幕有一个“忘记密码？”链接，点击后打开重置表单。
• 提交已注册的电子邮件地址后，一分钟内发送重置链接。
• 重置链接仅可使用一次，并在 30 分钟后过期。
• 新密码必须符合现有的密码规则，且表单需指出哪条规则未通过。
• 重置成功后，该账户的所有其他会话将被注销。
• 提交未注册的地址会显示与已注册地址相同的确认消息，因此表单不会泄露谁拥有账户。

当行为逻辑简单明了时，可以使用检查清单。其缺点是隐藏了初始状态和事件顺序，而下一格式会将这些内容明确表达。

格式 2：Given/When/Then（Gherkin）验收标准

Given/When/Then 源自行为驱动开发，Dan North 与 Chris Matts 在 Introducing BDD中对此进行了描述。每个场景都包含一个起始上下文（Given）、一个操作（When）和一个预期结果（Then）。 Gherkin 是 Cucumber 等工具使用的该语言的结构化版本，因此以这种方式编写的场景只需少量改写即可转化为自动化测试。

以下是同一密码重置故事中的三个场景，包括两个异常路径。

场景 1：使用有效链接重置

• 前提：我拥有一个注册在 anna@example.com 的账户
• 并且我已请求重置密码
• 当：我在 30 分钟内打开重置链接，并输入符合规则的新密码
• 那么：我的密码已更改
• 并且：我已登录
• 并且：我的其他会话已注销

场景 2：链接已过期

• 前提：我在 30 分钟前请求了密码重置
• When 我打开重置链接
• Then 我看到一条链接已失效的消息
• 并且：系统提供一个按钮以发送新链接

场景 3：电子邮件地址未注册

• 前提：不存在注册在 sam@example.com 的账户
• 当：我为 sam@example.com 请求密码重置
• 那么：我看到与已注册用户相同的确认消息
• 并且：没有发送任何电子邮件

当一个场景需要配合多种输入运行（例如，一组应被拒绝的密码列表）时，Gherkin 的 Scenario Outline 允许您编写一次，并在示例表中列出这些输入。

保持 Gherkin 的可读性：每个场景仅描述一种行为，并使用声明式写法（“当：我请求重置链接”）而非逐步点击式写法（“当：我点击发送按钮”），以便场景在重新设计后依然适用。

格式 3：基于规则的验收标准

对于主要由业务规则构成的故事（定价、资格、验证、权限），直接陈述规则，并仅为复杂组合添加场景。

故事：作为购物者，我希望在结账时应用折扣码，以便支付促销价格。

• 规则 1：每个订单仅限使用一个折扣码。
• 规则 2：百分比折扣码仅适用于产品小计，不适用于运费或税费。
• 规则 3：设有最低消费额的折扣码，仅在折扣前的小计达到最低消费额时适用。
• 规则 4：已过期或已用完的折扣码将被拒绝，并显示说明原因的消息。
• 规则 5：移除商品导致小计低于最低消费额时，折扣码将被移除并显示通知。

您可以在一个用户故事中混合使用多种格式。一种常见模式是：用规则描述逻辑，并用两到三个 Given/When/Then 场景来覆盖人们最容易误解的情况。

就绪定义与完成定义

验收标准针对单个用户故事。就绪定义和完成定义是适用于所有用户故事的团队级共识。

The Scrum 指南 将完成定义定义为增量在满足产品质量要求时所处的状态的正式描述。就绪定义不属于 Scrum 框架；它是许多团队采用的一种实践，旨在防止理解不充分的任务进入冲刺（参见 Agile Alliance 术语表中的 就绪定义 和 完成定义).

就绪定义示例

• 用户故事遵循模板，且“so that”部分已填写。
• 验收标准由产品、开发和测试人员共同编写并审查。
• 设计稿已关联，或团队已达成一致认为无需设计稿。
• 依赖项已完成或已排期。
• 团队已完成估算，且该故事可容纳在一个冲刺内。

完成定义示例

• 所有验收标准均已通过。
• 代码已审查并合并至主分支。
• 自动化测试覆盖新行为，且全部测试套件通过。
• 通过基本可访问性检查（键盘操作、标签、对比度）。
• 已部署到预发布环境，且产品负责人已验收通过。

将“完成定义”视为用于优化的检查清单，而非一道关卡。如果团队拒绝每一个未完全勾选所有项目的故事，工作进度就会放缓，而故事本应引发的对话也永远不会发生。

实际案例

来自不同产品类型的另外两个故事。更多四十个案例，请参阅我们的 用户故事示例.

SaaS：邀请团队成员（检查清单）

作为工作区管理员，我希望通过电子邮件邀请团队成员，以便他们无需共享我的登录信息即可查看我们的项目。

• 管理员在成员页面看到“邀请”按钮；其他角色则看不到。
• 管理员在发送前可以选择角色（成员或管理员）。
• 邀请邮件在一分钟内送达，且链接在七天内有效。
• 邀请已是成员的地址时，显示提示信息，而不是发送第二次邀请。

电子商务：稍后保存商品（Given/When/Then）

作为尚未准备好购买的购物者，我希望将商品从购物车移至保存列表，以便我稍后能找到它，且不影响我的订单总额。

• 假设我已登录且购物车中有两件商品
• 当我对其中一件商品选择“稍后保存”时
• 那么该商品移至我的保存列表
• 并且我的购物车总额在不包含该商品的情况下重新计算
• 假设我未登录
• 当我选择“稍后保存”时
• 那么系统提示我登录，登录后该商品被保存

在 Jira、Linear、Notion 或电子表格中使用模板

在 Jira 中，使用 Story 问题类型并将模板粘贴到描述中（如果管理员已添加专用字段，也可将验收标准保留在该字段中）。在 Linear 中，将其保存为问题模板。在 Notion 中，将其放入数据库模板，以便新的待办事项页面打开时已预填内容。对于首个待办事项列表或研讨会，使用每行对应一个故事的电子表格即可，但一旦多人同时编辑，就应迁移到跟踪工具。无论使用何种工具，都要保持模板简短，以便人们愿意填写。

使用 AI 起草故事和验收标准

语言模型擅长生成故事和标准的首稿。一个有效的提示词如下：

你是一名产品经理。针对以下功能，按“作为[用户]，我希望[操作]，以便[收益]”的格式编写用户故事。为每个故事添加 3 到 6 条 Given/When/Then 形式的验收标准，其中至少包含一条异常路径。单独列出任何假设和待解决问题。功能：[描述功能、用户及任何约束条件]。

然后像审查其他输入一样审查该草稿：

• 该用户是你实际访谈过的真实用户群体，还是泛指的“用户”？
• 模型是否虚构了业务规则、限制或数字？请用你自己的内容替换它们。
• 异常路径是否为用户实际遇到的情况？草稿永远无法替代优化对话。

常见问题

希望团队将您的故事转化为可用软件？带上您的待办事项列表，或仅带上想法，我们将帮助您将其塑造为冲刺规模的故事并构建它。查看 我们的月度开发计划.