用户故事怎么写，团队才容易理解？

迭代规划会上，产品经理讲完用户故事，开发追问：这到底给谁用？测试追问：做到什么程度算完？会议室安静了几秒。

敏捷联盟发布的《敏捷实践指南》把用户故事列为Scrum团队管理产品待办列表的常用方式。

用户故事怎么写更容易被团队理解？这篇文章会从角色、价值、验收三个关键点，给出可复用的写法和自检方式。

一、团队看不懂的用户故事

1. 功能清单当故事用

常见的第一类问题是把用户故事写成功能清单。没有使用者和使用价值，开发看了知道要做什么，不知道为什么要做；测试看了不知道重点验什么，只能按界面流程走一遍。

这种写法本质上是需求说明书，不是用户故事。

用户故事要回答的是用户在这个功能里获得什么结果，而不是系统内部要做哪些动作。

2. 角色、价值句不清晰

第二类问题是角色不清晰，价值句缺失。比如“作为用户，我希望有找回密码功能”——“用户”的范围很宽，是注册用户、管理员还是访客？把角色写清楚，团队才能代入真实场景。

价值句部分也同理，找回密码是为了重新登录账号，还是为了换一个新密码？缺了角色和价值，故事就停在功能描述层面。

3. 太笼统或过度具体

第三类问题是尺度拿不准。笼统的写法，比如“用户想要更好的体验”，无法估算、无法测试，团队只能自行发挥；过度具体的写法，比如“点击蓝色按钮、弹出400px弹窗”，把设计和实现路径提前锁死，团队没有协商空间。模糊和僵化都会让团队无法对齐。

二、按顺序改写一个用户故事

下面用找回密码功能的用户故事案例演示改写。

1. 先定义角色说清给谁用

“作为用户，我希望有找回密码功能”。这个写法的第一个问题是角色等于没写，应当把角色定成忘记密码的注册用户。一个故事只服务一个明确角色，不要试图让一个故事覆盖全场景。

如果团队反复纠结角色写多具体才够，可以提前为产品建立两到三个典型用户画像，包括他们的使用场景、设备习惯、常见痛点。例如“张先生，三十五岁，普通上班族，使用公司邮箱注册，偶尔忘记密码”。

有了画像池，每次写故事时直接选用匹配的画像名称，角色定义就变得标准化。画像可由产品经理维护，定期根据用户调研更新。

2.补上价值句

接下来补价值句，改成：“作为忘记密码的注册用户，我希望通过邮箱验证码重置密码，以便重新登录账号。”

在标准格式里，这个“以便”部分就是价值句。它的作用是把重置密码从一个功能动作，变成用户目标，让团队清楚为谁做、为什么做。

用户故事模板通常就是三段式：“作为某类角色，我希望完成某件事，以便获得某种价值”。如果价值句写不出来，说明需求没有想清楚，应该回到用户那里继续问。

3. 用 INVEST 自检

改写之后，用 INVEST 原则过一遍。

INVEST 包括独立、可协商、有价值、可估算、足够小、可测试六个方面。

• 独立：故事之间尽量少依赖。有依赖不等于不合格，关键是团队清楚依赖并安排好先后顺序。

• 可协商：故事只表达意图，实现方式留给团队讨论。

• 有价值：对用户有可感知的结果。

• 可估算：团队能据此判断工作量。

• 足够小：大小适合放入一个迭代容量内。

• 可测试：有明确验收标准。

对照上面的“重置密码”例子，该故事可以独立交付（依赖是邮件服务，需提前约定接口）；邮箱验证码方式可协商；找回账号对用户有价值；工作量两天内可估算；大小适合一个迭代；有明确的验收标准。哪条不满足就改哪条。如果故事太大，就按用户目标拆分。

4. 补验收标准和完成定义

验收标准写得越具体，需求对齐就越可检查。

围绕“重置密码”，可以写这几条：提交邮箱后六十秒内收到验证码邮件；验证码十分钟内有效；连续输错五次锁定账户三十分钟；重置后可用新密码登录。验收标准把完成定义写清楚，开发据此判断完成，测试据此设计用例。

团队还可以配一条统一的完成定义（Definition of Done），比如“代码合入、测试通过、文档更新”。两者一起用，需求和交付之间的缝隙会小很多。

用户故事的第一稿通常由产品经理或业务分析师起草。最好在需求梳理会上与团队共同打磨，或至少先写一个粗稿，再邀请开发与测试补充边界条件。关键是从一开始就纳入多方视角，而不是写完再通知团队。

验收标准则由产品经理负责提出业务验收点，开发和测试负责补充技术边界，如性能、异常、安全等。最终由三方共同确认，产品经理录入系统并保持更新。

如果需求发生变化，验收标准应当同步调整，产品经理承担维护责任，但团队也有义务及时反馈变化。

5. 用一页纸讲给团队听

写法改好之后，最后是“讲”。讲的时候建议按角色、场景、价值、验收标准四个信息展开，比如：忘记密码的注册用户，在登录失败时收到验证码，重置后能重新登录；验证码有效十分钟，过期可重发。

这样讲完，产品、开发、测试对做什么、为什么做、怎么做算完成会形成一致理解。

讨论结论应作为需求记录留存。如果团队需要把故事落到可追踪需求，可以把用户故事作为需求条目放进项目管理工具。把用户故事和用例、任务、缺陷关联跟踪，讨论记录和交付过程放在一处。

6. 优先级排序：决定先做哪个

故事写清楚，但冲刺容量有限，这时候就要对用户故事进行排序。

推荐使用 MoSCoW 法则或价值‑风险矩阵。

MoSCoW 将故事分为必须做（否则产品不可用）、应该做（重要但可暂缓）、可以做（锦上添花）、不做（本次不纳入）。每个冲刺至少保证必须做的全部完成，再视容量拉入应该做的。

价值‑风险矩阵则优先做高价值、低风险的故事；对高价值、高风险的，先做技术验证或拆解；对低价值的，考虑是否真的需要做。

优先级排序应在需求梳理会和冲刺规划中反复讨论，产品经理拥有最终决策权，但须听取开发对风险与成本的评估。优先级不是一成不变的，每个冲刺结束后应根据反馈重新审视。

三、常见问题解答

用户故事和需求文档有什么区别？

用户故事是讨论的起点，用两三句话表达角色、功能、价值；需求文档是交付契约，写清规则和流程。敏捷团队多用故事，合规场景多用文档，多数团队两者结合。如果团队已经习惯文档，建议先写故事卡对齐价值，再以故事卡为大纲补充合规所需的详细规则附件，用同一标识关联两者，不必二选一。

用户故事一定要写成三段式吗？

不一定。三段式是帮助对齐的起点，不是死规矩。能说清角色、价值、验收标准，格式可以灵活调整。有的团队用一句话加若干补充说明，也是常见做法。关键是团队读起来一致。

技术类工作怎么写成用户故事？

把技术目标转成用户可感知的价值。比如“重构登录模块”如果是为了提升响应速度，可以改为“用户提交登录请求后两秒内看到跳转”。

但要注意，重构有时纯粹为了代码可维护性，不改变外部行为，这种情况下不建议硬套故事格式，直接作为技术任务或技术债卡片单独管理。两者在需求管理工具中可以分开跟踪。

最后，用户故事怎么写团队才容易理解？判断标准很简单：故事讲完，团队能回答出“给谁用、做什么、为什么做、怎么做算完成、现在要不要做”。如果这五句话都能对上，用户故事就算写明白了。

下次写用户故事前，多花几分钟做一次角色、价值、验收、优先级和依赖关系的自检，需求对齐会顺利很多。