User Story - 用 Mike Cohn 格式与 Gherkin 验收标准写规范的用户故事

技能概述

User Story 是一个产品经理组件技能,结合 Mike Cohn 的用户故事格式(As a / I want to / so that)与 Gherkin 验收标准(Given / When / Then),帮你把用户需求快速转化为开发就绪、可测试的用户故事。

适用场景

1. Backlog 梳理与 Sprint 规划:在迭代规划前快速起草格式统一的用户故事,让产品、工程、QA 用同一套语言讨论需求。
2. 将 PRD 需求转换为用户故事:把产品需求文档中的一段功能描述,改写成包含角色、动机和可验证验收标准的开发就绪故事。
3. 为新功能编写带验收标准的需求:例如为 B2B SaaS 应用的通知系统、登录方式等新功能,写清"谁受益、做什么、为什么、怎样算完成"。

核心功能

1. Mike Cohn 用例格式:按"作为[角色],我想要[操作],以便[期望结果]"的结构写用例,强制聚焦谁受益、做什么、为什么有价值,避免只复述功能点。
2. Gherkin 验收标准:用 Given(前置条件)/ When(触发事件)/ Then(预期结果)编写验收标准,多条 Given 允许叠加,但保持单一 When 和单一 Then,确保 QA 能直接据此写测试用例。
3. 质量检查与反模式提醒:内置常见错误清单——如"As a user"过于笼统、"so that"复述"I want to"、多个 When/Then 说明故事过大需要拆分、"Then"不可度量等,帮你写出符合 INVEST 原则的故事。

常见问题

用户故事和 PRD 有什么区别?

PRD 是较完整的功能规格说明,而用户故事是对话的开场白:它用一两句话讲清"谁在什么情况下想要什么、为什么",再用 Gherkin 验收标准定义"怎样算完成"。这个技能的定位就是把 PRD 中的需求点改写成这种轻量、可测试的故事格式,而不是替代 PRD。

什么时候应该拆分用户故事?

当验收标准出现多个 When 或多个 Then 时,通常说明一条故事捆绑了多个功能,应当拆分。此外,如果故事无法在一个迭代内完成、或无法被测试验证,也应先拆分再进入开发。

为什么"作为一名用户(As a user)"开头的故事不好?

"用户"过于笼统,不同角色的需求差异很大。应使用具体角色或画像,例如"作为试用用户""作为付费订阅者""作为管理员",这样故事才能准确反映真实使用动机,验收标准也更容易落到实处。

这个技能不适合处理什么?

纯技术债或重构类工作没有直接的用户价值,应使用工程任务而非用户故事;在尚未理解用户问题之前,也应先写问题陈述,再回头写故事。