本文内容整理于《用户故事与敏捷开发》，这本书介绍了用户故事的重要价值和实践方法，同时介绍了如何在敏捷开发方法中使用用户故事。

一、完整用户故事涉及内容

1）描述：在故事卡正面描述故事，最好以“作为（角色），我想要（功能），以此（商业价值）”的形式记录。

2）细节：在故事卡背面记录细节，在故事开始到结束记录测试要点，为确认故事是否被完整实现提供标准。

3）优先级：依照MoSCoW规则，可以将用户故事划分为四个优先级，必须有，应该有，可以有，这次不会有。

4）故事点：开发工作量，可以将一个理想日的工作看作一个故事点。

二、好用户故事的6个特征

1）独立的

用户故事之间应该是独立的，故事应该不受到交付顺序影响，可以拿任一个故事来实现。尽量避免故事之间具有依赖性，导致优先级划分困难。如果故事依赖，可以尝试将相互依赖的故事合并，或采取不同的故事切割方式。（故事切割见特征（5）小的）

2）可讨论的

用户故事是功能的简短描述，重要细节以注释的形式记录，以提供适量的信息给产品和开发交流。

3）对用户或客户有价值的。

用户故事必须是对用户或客户有价值，不必关注技术和实现细节，同时避免出现界面和技术的定义。

4）可估计的

用户故事可以供开发人员估算开发时间，如果不能估计，可能是故事太大，需要切割故事。

5）小的

对于史诗故事（非常大的故事）或复合故事，将故事进行切割。一是根据“创建”、“编辑”，“查看”等动作切割；二是根据数据边界、信息类别切割。但是像bug修复，界面优化的太小的故事，可以合并成一个单一故事。

6）可测试的

用户故事是具体的，可以被审核、验证、交付使用。例如“用户绝不需要花很长时间等待窗口实现”是不可测试的，可以优化为“在95%的情况下，新窗口会在2秒内打开”。

三、如何捕捞用户故事

用户故事有大有小，有生命会结束，会随着用户需求而变化，在项目初期可以采用以下方法捕捞不同层级的用户故事。

1）用户访谈：捕获新故事，多询问开放式问题和背景无关问题

2）问卷调查：在一个庞大的用户群中搜集用户故事优先级

3）观察：观察用户实际使用软件的情况

4）故事编写工坊：重点放在数量而不是质量。开发人员、用户、产品客户和其他可能有帮助的人共同参与，编写尽可能多的故事，但是不划分优先级。首先确定故事角色，画出简单的原型，询问当前用户角色能在这个界面做什么。原型示例如下图所示：