Neural Project Institute面向 AI 时代的项目管理认证

敏捷指南 · 敏捷实践

用户故事:如何编写(附模板和示例)

用户故事是以通俗语言、从用户角度编写的简短描述,说明用户需要什么。它记录了谁想要、想要什么以及为什么,并作为日后讨论细节的占位符,而不是一份完整的规格说明。

要点总结

  • 用户故事说明谁需要某样东西、需要什么以及为什么需要。
  • 验收标准使每个故事都可测试;完成的定义适用于所有故事。
  • 使用 INVEST 检查质量,并拆分无法在一个冲刺内完成的故事。
  • 故事是对话的起点,而不是完整的规格说明。

用户故事模板

最常见的格式是: 作为 [用户类型], 我希望 [某个目标] 以便 [某种收益]。

  • 谁: 具体的用户或角色,而不是“系统”。
  • 内容: 他们需要的目标或能力,而不是技术解决方案。
  • 原因: 收益,这有助于团队找到最简单的交付方式。

许多团队用三个 C 来描述故事: 卡片 (简短的书面故事)、 对话(Conversation) (补充细节的讨论)以及 确认(Confirmation) (表明其已完成的验收标准)。

验收标准

验收标准是故事被验收所必须满足的条件。它们使故事可测试,并减少误解。常见的两种形式:

  • 检查清单: “预约信息显示课程时间和地点”;“会员收到确认邮件”。
  • Given-When-Then: “假设某课程有空余名额,当会员点击‘预约’时,则保留一个名额,且空余名额数量减少一个。”

INVEST 检查清单

字母含义需要提出的问题
I独立(Independent)能否在不等待其他故事的情况下交付?
N可协商(Negotiable)细节是否可以讨论,而不是固定不变?
V有价值(Valuable)它是否为用户或业务带来价值?
E可估算(Estimable)团队是否足够理解它,从而能够进行估算?
S小(Small)能否在一个冲刺内完成?
T可测试(Testable)是否有明确的验收标准?

如何逐步编写用户故事

  1. 确定用户及其目标,最好基于调研或真实反馈。
  2. 使用模板编写故事,控制在一两句话以内。
  3. 添加三到六条验收标准。
  4. 在以下活动中与团队讨论: 待办事项列表梳理 并进行调整。
  5. 对照 INVEST 进行检查;如果过大就进行拆分。
  6. 对其进行估算,例如使用 故事点.
  7. 在以下位置对其排序: 产品待办事项列表 中,依据价值、风险和依赖关系进行排序。

示例:较差的与改进后的

较差的故事改进后的故事
作为用户,我希望有一个用于预约的数据库表。作为会员,我希望预约课程,以便为我保留名额。
作为系统,我希望发送电子邮件。作为会员,我希望收到预约确认邮件,以便留存课程记录。
作为用户,我希望网站运行速度快。作为移动端用户,我希望课程表在两秒内加载完成,以便随时随地预约。
作为管理员,我希望有一个包含 15 份报表的报表模块。作为健身房经理,我希望查看每节课程的每周出勤情况,以便调整课程表。

完整示例: 作为会员,我希望在课程满员时加入候补名单,以便在有人取消时获得名额。 验收标准: 只有在课程满员时才显示“加入候补名单”按钮;会员可以看到自己的排位;有名额空出时,系统通过电子邮件将名额提供给排在第一位的人,其有两小时时间接受。

常见错误

  • 把技术任务伪装成故事来编写。
  • 故事过大以至于跨越多个冲刺;应将其视为 史诗 并将其拆分。
  • 缺少“以便”从句,掩盖了真实需求。
  • 把故事当作合同,而不是以此开启对话。
  • 验收标准缺失或模糊,导致返工。
  • 即使一句普通的话更清楚,也坚持用模板编写每个故事。

本主题的免费模板

浏览所有模板

常见问题

敏捷中的用户故事是什么?

从用户角度编写的用户需求简短描述,由团队将其转化为可用的功能。

用户故事的格式是什么?

作为 [用户类型],我希望 [目标],以便 [收益]。

谁来编写用户故事?

任何人都可以编写,但通常由产品负责人负责确保它们清晰明确,并在待办事项列表中排好顺序。

用户故事是 Scrum 的一部分吗?

不是。《Scrum 指南》讨论的是产品待办事项列表条目;用户故事是编写这些条目的一种流行方式。

用户故事中的验收标准是什么?

故事必须满足才能被验收的具体、可测试的条件,通常以检查清单或 Given-When-Then 形式编写。

用户故事应该多小?

小到足以在一个冲刺内完成,最好在几天内完成。

用户故事中的 INVEST 代表什么?

独立(Independent)、可协商(Negotiable)、有价值(Valuable)、可估算(Estimable)、小(Small)和可测试(Testable)。

用户故事和需求有什么区别?

传统需求详细规定系统必须做什么;用户故事描述一项需求,并通过对话来商定细节。参见 项目需求.

用户故事和史诗有什么区别?

所谓 史诗 是由许多故事组成的大型工作;一个故事可以在单个冲刺内完成。

如何估算用户故事?

大多数团队使用相对规模估算,例如 故事点 或 T 恤尺码,由团队共同商定。

用户故事可以在软件以外的领域使用吗?

可以。营销及其他团队也会编写故事,例如“作为潜在客户,我希望看到价格对比,以便选择套餐”;参见 敏捷营销.