总结

用户故事可能是在捕获产品功能方面流传最广泛的敏捷实践。
利用用户故事来工作是容易的，但是讲述有效故事却是有困难的。
如下的10个提示能帮助到写好用户故事。

1 用户先来

如同名字所说明，一个用户故事描述了一个顾客或者一个用户如何使用产品；它是从用户角度来书写的。更重要的是，用户故事对于捕捉一个特定的功能特别有帮助，如，搜索产品或预订。

如果你不知道用户和客户是谁，以及他们为什么要使用该产品，那么你不应该写任何用户的故事。首先进行必要的用户研究，例如，通过观察和访谈用户。否则，你就是冒险写故事，那些故事只是基于信念和想法，而不是数据和经验证据的。

2使用Persona方法来发现正确的故事

用于捕获你对于用户和客户的见解的一个伟大技术是人物角色刻画（Persona方法）。Persona是虚构的人物，是基于目标群体的第一手知识。Persona通常由一个名字和一张图片，相关的特点，行为和态度，和一个目标。目标是角色想实现的利益，或者角色想通过使用产品解决的问题。
但还有更多：人物角色的目标帮助你发现正确的故事：问自己的产品应提供什么样的功能来满足人物角色的目标。可以下载一个方便的模板来描述人物角色，参见 romanpichler。

3协同创作故事

用户故事不是一个规范，而是一个沟通和协作工具。故事不应该仅仅是交给一个开发团队，而是他们应该被嵌入在对话中：产品主管和团队应该一起讨论故事。
你可以采取进一步的合作来写故事，例如，作为你的产品待办列表优化过程的一部分。这充分利用了团队的创造力和知识，并得到更好的用户故事。
如果你不能在用户故事工作中让开发团队参与，那么你应该考虑使用另外更正式的技术来捕获产品的功能，例如，用例。

4保持故事简洁明了

写故事，让他们容易理解。保持简洁明了。避免混淆和模棱两可的术语，并使用主动语态。专注于什么是重要的，放下其余的。
下面的模板将用户或客户建模为一个人物角色的故事，并使其利益显式。它是基于Rachel Davies的流行的模板，但我已经用人物角色的名字取代了用户角色，用于连接故事与相关的人物角色。
作为<人物角色名字>，
我想要<什么？>
那么<为什么？>。
使用模板时，它是有帮助的，但不觉得有义务总是适用于它。尝试不同的方法来写你的故事，了解什么是最适合你和你的团队。

5从史诗开始

史诗是一个大的、粗略的、粗粒度的故事。随着时间的推移，利用用户对于早期原型和产品增量的反馈，它通常会被分解成多个用户故事。你可以认为它是更详细的故事标题占位符。
从史诗开始，让你勾勒出产品的大功能而不是细节。这对描述新的产品和功能是特别有帮助的：它可以让你捕捉到粗糙的范围，它需要你后续时间来了解更多关于如何最好地满足用户的需求。它也减少了用于整合新见解的时间和精力。如果你在产品待办列表中积累了许多详细的故事，那么它往往是棘手的，并且需要耗费更多时间来获取反馈修改到适当的故事，你必须小心，不要引入不一致。

6优化故事，直到他们准备好

打破史诗到较小的、具体的故事，直到他们准备好：明确的，可行的，和可测试的。所有的开发团队成员应该有一个共同对故事意义的理解；这个故事不应该太大，适合放在一个冲刺中，并有一个有效的方法来确定故事是否完成。

7添加接受标准

当你为小故事打破史诗，记得加接受标准。接受标准可以用叙述来说明，描述故事完成的条件，只有这些条件达成了，故事才能判断为完成。接受标准使得故事更加丰富，变得可测，保证故事可以展示或发布给用户和其他利益相关者。作为一个经验法则，我喜欢用三到五的接受标准来详细的故事。

8使用纸卡

用户故事是在极限编程（XP）中出现的，早期的XP文字谈论多的是故事卡片而不是用户故事。有一个简单的原因：用户故事被写在纸上。这种方法提供了三个好处：一是，纸卡便宜，使用方便。第二，促进合作：每一个人都能拿出一张卡片，写下一个想法。第三，纸片可以很容易地分组在桌上或墙上，检查一致性和完整性，并且把依赖可视化。即使你的故事是以电子方式储存的，当你写新的故事时，也值得使用纸质卡片。
【译者说明：对于拥有Story工具+触摸屏的团队而言，纸卡不再是需要了，Story工具+触摸屏组合能够获得以上的所有好处，并且实时同步版上拖动操作与Story工具中操作，也便于异地合作，这2个方面是优于纸质卡片的，当然工具+触摸屏需要更多的成本】

9保持你的故事是可见的和可访问的

故事要传达信息。因此不要将它们隐藏在网盘、企业内部网丛林或许可的工具上。使他们可见，例如，把他们放在墙上。这促进了合作，创造了透明度，并使它很明显，当你添加太多的故事太快，可能很快用光了墙壁空间。
【译者说明：如果使用了Story工具，它应当是线上工具，团队成员和干系人，无论身在何处，都能随时访问。】

10不要仅仅依靠用户故事

创造一个伟大的用户体验（UX）需要更多的用户故事。用户的故事有助于捕获产品的功能，但他们不适合描述用户的体验流程和视觉设计。因此，补充用户故事与其他技术，如故事地图，流程图，故事板，素描，和模型。
此外，用户故事并不是很好的需求捕获技术。如果你需要沟通一个什么架构元素，比如组件或服务，那么写技术故事或是建模语言UML。
最后，当你开发的软件很有可能被重用，编写用户故事是值得的。但是如果你想快速创建一个一次性的原型或模型来验证一个想法，然后写故事可能不是必要的。记住：用户的故事并不是关于文档的需求，他们想让你快速移动和开发软件，尽快不施加任何开销。

https://blog.csdn.net/zhangmike/article/details/52198745