用户故事的定义
在软件开发和产品管理中，用户故事是对软件系统功能的非正式、自然语言的描述。它们是从最终用户或系统用户的角度编写的，可以记录在索引卡、便利贴上，也可以数字形式记录在特定的管理软件中。用户故事根据不同产品可能由不同的利益相关者撰写，如客户、用户、经理或开发团队。
用户故事是一种边界对象，促进了干系人的感知和交流，并且可以帮助软件团队记录他们对系统及其背景的理解。
发展历史
1997年：Kent Beck在底特律的克莱斯勒C3项目中导入了用户故事。
1998年： Alistair Cockburn参观了C3项目，并首次表示“用户故事是对话的承诺”。
1999年：Kent Beck出版了《极限编程解释》一书的第一版，介绍了极限编程（XP）以及用户故事在计划游戏中的使用。
2001年：Ron Jeffries提出了一个用户故事创作的“三个C”公式：
1.卡片。（或者通常是一张便利贴）是一种有形的物理标记，用来存放概念；
2.对话。是在利益相关者（客户、用户、开发人员、测试人员等）之间进行的。它是口头的，经常以文件作为补充；
3.确认。确保对话达成一致的目标。
2001年：位于伦敦的Connextra的XP团队设计了用户故事格式，并与其他人分享了示例。
2004年：Mike Cohn在其著作《应用的用户故事：敏捷软件开发》中概括了超越卡片使用的用户故事原则，Martin Fowler认为这本书现在被认为是该主题的标准参考。科恩称Rachel Davies是用户故事的发明者。
2014年 Jeff Patton于2014年发表了用户故事映射技术，该技术旨在通过系统的方法改进用户故事的识别，并对故事进行结构化，以更好地了解其相互依存性。
用户故事的原则
用户故事由用户或客户编写（或产品负责人为用户或客户撰写），以影响正在开发的系统的功能。在一些团队中，产品经理（或Scrum中的产品负责人）主要负责编写用户故事并将其组织到产品积压清单中。在其他团队中，任何人都可以编写用户故事。用户故事可以简单地编写以支持基于任务角色与利益相关者的讨论。
一个好的用户故事应该遵循INVEST原则（INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable）。
独立性（Independent）— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划，确定优先级，工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
可协商性（Negotiable）— 一个用户故事的内容要是可以协商的，用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述，不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节，实际上限制了和用户的沟通。
有价值（Valuable）— 每个故事必须对客户具有价值（无论是用户还是购买方）。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候，他们将非常乐意写下故事。
可以估算性（Estimable）—开发团队需要去估计一个用户故事以便确定优先级，工作量，安排计划。但是让开发者难以估计故事的问题来自：对于领域知识的缺乏（这种情况下需要更多的沟通），或者故事太大了（这时需要把故事切分成小些的）。
短小（Small）— 一个好的故事在工作量上要尽量短小，最好是2～3点可以被完成，至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大，在安排计划，工作量估算等方面的风险就会越大。
可测试性（Testable）—一个用户故事要是可以测试的，以便于确认它是可以完成的。如果一个用户故事不能够测试，那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子：软件应该是易于使用的。
常用编写格式
用户故事可能遵循几种格式或模板中的一种。
最常见的是Connextra模板，如下所述（尽管“以便“这部分内容被认为是游泳的，但是Mike Cohn建议它是可选的。
As a I can , so that
作为一个＜角色＞，我可以＜具备某种能力＞，以便＜获得利益＞
Chris Matts建议“寻找价值”是成功交付软件的第一步，并提出了这种替代方案：
In order to as a , I can <goal/desire>
为了＜获得利益＞，作为一个＜角色＞，我可以＜目标/欲望＞
另一个基于五个W的模板规定：
As , I want because
作为<谁><何时><何地>，我想要<某物>，因为<某种原因>
通常用于提高安全性的模板被称为“邪恶用户故事”或“滥用用户故事”，它被用作一种像黑客一样思考的方式，以考虑网络攻击中可能发生的场景。这些故事是从攻击者试图破坏或破坏应用程序的角度编写的，而不是从用户故事中的典型人物角色的角度：
作为一名心怀不满的员工，我想清除用户数据库以伤害公司
用户故事示例：
筛选测试（史诗故事）
作为人力资源经理，我想创建一个筛选测试，这样我就可以了解是否要向职能经理派遣合适的招聘人员。
测验回忆
作为一名经理，我想浏览我现有的测验，这样我就可以回忆起我现有的内容，并弄清楚我是否可以重新使用或更新现有的测验来满足我现在需要的职位。
有限的备份
作为用户，我可以示意不备份文件夹，这样我的备份驱动器就不会装满我不需要保存的东西。
用法
作为许多敏捷开发方法的核心实践（例如在极限编程的规划游戏中，用户故事描述了软件产品中可能构建的内容）。用户故事由客户（或Scrum中的产品负责人）排定优先级，以表明哪些对系统最重要。由开发人员进行评估（通常采用斐波那契数列进行规模估算），并分解为任务。
当用户故事即将要进入实现阶段，开发人员应该适时与客户进行沟通。简短的故事可能难以理解，需要一些需求相关的背景知识以及自故事编写以来需求发生的变化。
用户故事可以根据这些对话进行扩展以添加细节。这可能包括注释、附件和验收标准。
验收标准
Mike Cohn将验收标准定义为“关于故事必须做什么才能让产品所有者接受它是完整的”。它们定义了用户故事的边界，用于确认故事何时完成并按预期工作。
验收标准中包含的适当信息量因团队和项目而异。有些可能包括“前置条件”，“用户已经登录并编辑过他的信息一次”。可以用典型的敏捷格式写下接受标准，Given – When – Then，或者可能只是简单地使用从客户或利益相关者那里收集的原始需求中提取的要点。为了使故事被认为已经完成，交付物必须满足所有验收标准。
与Epic、主题以及项目集的关系
用户故事通常被按照某些原因被组织在一起。在某些大规模的框架下，用户故事与项目集相关联。这些不同的用法取决于看待需求的视角，比如从用户的视角作为产品负责人就以特性归类，从企业的视角可能又按任务组织。
提案Initiative
多个主题、史诗或故事按层次组合在一起而形成的总体方案。
主题Theme
多个史诗或许多非常大且密切相关的故事被总结为主题。史诗的一个常见解释也是：需要跨越多个Sprint的工作，或者在规模化框架中发布火车以及解决方案火车层面的需求。
史诗Epic
用户故事通过基于一定逻辑关系聚合在一起形成的需求组。
用户故事地图
用户故事地图根据呈现产品全貌的叙事流程来组织用户故事。该技术由Jeff Patton于2005年至2014年开发，旨在解决项目中充斥着非常详细、零散的用户故事所带来的实现产品目标注意力被分散的风险。
用户故事地图使用与用户的研讨会来首先确定主要的业务活动。这些主要活动中的每一个都可能涉及几种类型的用户或人物角色。
然后，通过识别参与这些业务活动的个人用户的主要任务，绘制出横向叙述线。这条线在整个项目中都保持不变。更详细的用户故事会像往常一样通过用户故事实践进行收集和整理。但每个新的用户故事要么直接被插入到流程中，要么与主要任务垂直相关。通过这种方式，甚至可以在不丢失大局的情况下描述大型系统。
故事地图可以很容易地提供产品积压工作的二维图形可视化：在地图的顶部是故事分组的标题，通常被称为“史诗”（大的粗粒度用户故事）、“主题”（相关用户故事的集合）或“活动”。这些是通过定位用户的工作流程或“解释系统行为的顺序”来识别的。故事卡是在对应的Epic下面垂直地按优先级分配和排序的。第一排水平轴是一个“行走的骨架”，而纵轴代表着越来越复杂的需求细节。
