用户故事可能是捕获产品功能的最流行的敏捷技术：使用用户故事很容易。但讲出有效的故事可能很难。以下十个技巧可以帮助您创建好的故事。
1. 用户第一
顾名思义，用户故事描述了客户或用户如何使用产品，它从用户的角度进行表达。另外，用户故事特别有助于捕捉特定的功能，例如搜索产品或进行预订。下图说明了用户，故事和产品功能（由圆圈表示）之间的关系。
如果你不知道谁是用户和客户，以及为什么他们会想要使用这个产品，那么你不应该写任何用户故事。首先进行必要的用户研究，例如通过观察和访问用户。否则，就有基于自己的想法和信念写出假想的故事的风险，而不是基于数据和经过验证的证据。
2. 使用角色来发现正确的故事
捕捉用户和客户的见解的一个很好的技术就是使用人物角色（Persona）。人物角色是基于目标群体的第一手知识的虚构人物。他们通常由一个名字和一张照片组成，还包括相关的特征、行为和态度、以及一个目标。目标是人物想要获得的利益，或者人物想要通过使用产品来解决的问题。
除此之外还有：人物角色的目标可以帮助你发现正确的故事：问问自己，为了达到人物角色的目标，产品应该提供什么样的功能。正如我在“ 从角色到用户故事” 的文章中解释的那样。您可以从romanpichler.com/tools/persona-template下载一个方便的模板来描述您的角色。
3. 合作创作故事
用户故事旨在作为一种轻量级的技术，使您能够更快。他们不是一个规范，而是一个协作工具。故事不应该交给开发团队。相反，他们应该被嵌入到一个对话中： 产品负责人（PO）和团队应该一起讨论这些故事。这使您只能捕获最少量的信息，减少开销并加速交付。
您可以进一步采取这种方法，让团队协作来写故事，这可以是产品backlog梳理过程中的一个环节。如果你不能让开发团队参与用户的故事工作，那么你应该考虑使用另一种更正式的技术来捕获产品功能，例如用例。
4. 保持你的故事简单和简洁
写下你的故事，以便他们很容易理解。保持简单和简洁。避免混淆和模棱两可的条款，并使用主动语态。专注于重要的东西，而忽略其余的东西。下面的模板将用户或客户建模为一个人物角色，并使其好处明确。它基于Rachel Davies的流行模板，但是我已经用人物角色（Persona）替换了用户角色（Role of User），将故事与相关角色联系起来。
作为<persona>,
我想要<what？>
以便<why？>。
有用时使用该模板，但不要总是使用它。尝试用不同的方法来写你的故事，以了解什么对你和你的团队最有效。
5.从Epics开始
史诗是一个大而粗略，粗糙的故事。它通常会随着时间的变迁而分解成多个用户故事 – 基于用户对早期原型和产品增量的反馈。你可以把它看作是一个标题和一个更详细的故事的占位符。
从史诗故事开始，能够让你在不关注太多产品详细信息的情况下捕获产品的功能。这对于描述新的产品和功能特别有帮助：它可以让您捕捉到粗略的范围，这节省了你了解如何最好地满足用户的需求的时间。
这也减少了整合新想法所需的时间和精力。如果在产品Backlog中有很多详细的故事，那么将反馈和对应的条目关联起来往往是非常棘手和耗时的，并且还有导致信息不一致的风险。
6.细化故事，直到准备就绪
把你的史诗分成更小，更详细的故事， 直到准备就绪：清晰，可用，可测试。所有的开发团队成员应该对故事的意义有一个共同的理解; 这个故事不应该太大且能放到一个Sprint，还必须有一个有效的方法来确定故事是否完成。
7.添加验收标准（AC）
当你把史诗分成更小的故事时，请记住添加验收标准。验收标准补充叙述：它们用来描述故事达到完成必须完成的条件。验收标准丰富了故事，使其成为可测试的，并确保故事可以演示或发布给用户和其他干系人。作为一个经验法则，我喜欢给详细的故事添加三到五个验收标准。
8.使用纸卡
用户故事出现在极限编程（XP）中，早期的XP文献讲述了故事卡而不是用户故事。有一个简单的原因：用户故事被捕获在纸卡上。这种方法提供了三个好处：首先，纸卡便宜且易于使用。其次，他们促进合作：每个人都可以拿一张卡片并记下一个想法。第三，卡片可以很容易地分组在桌子或墙上，以检查一致性和完整性，并可视化依赖关系。即使你的故事是以电子方式存储的，当你写新的故事时，使用纸卡也是值得的。
9.保持你的故事可见和可访问
故事要传达信息。因此，不要将其隐藏在你的服务器和电脑上。你可以把它们放在墙上，使它们可见。这会促进协作，创建透明度，而且你可以很快的发现你过快地添加了太多的故事，因为你的墙面快用完了。
我有一个方便的工具可以帮助你来发掘、可视化和管理你的故事，这就是我的产品画布。
如下所示。
10 不要单靠用户故事
创造出色的用户体验（UX）需要的不仅仅是用户故事。用户故事有助于捕捉产品功能，但不能很好地描述用户旅程和 视觉设计。因此，可以用其他技术来补充用户故事，例如故事地图，工作流程图，故事板，草图和模型。
另外，用户故事不能很好地捕捉技术要求。如果您需要传达像组件或服务这样的架构元素应该做什么，那么请编写技术故事，或者，根据我的偏好——使用像UML这样的建模语言。
最后，在开发可能被重用的软件时，编写用户故事是值得的。但是，如果你想快速创建一个一次性原型或模型来验证一个想法，那么写故事可能不是必要的。记住：用户故事不是关于记录需求; 他们希望能够使您更快并尽快开发软件，而不是强加额外的开销。
英文资料来源： http : //www.romanpichler.com/blog/10-tips-writing-good-user-stories/
作者：罗马·皮赫勒
译者：廖靖斌Eric Liao， Scrum中文网资深敏捷教练、顾问和培训师，CSP
