用户故事代表团队可以在迭代中交付的一小部分业务价值。
虽然传统需求（如用例）试图尽可能详细，但用户故事是逐步定义的，分为三个阶段：
- 需求的简要描述
- 在 backlog 细化和迭代计划期间发生的对话以巩固细节
- 确认故事圆满完成的测试
结构良好的故事将符合 Bill Wake 的 INVEST 首字母缩略词的标准：
- 独立的 (Independent) - 我们希望能够以任何顺序进行开发。
- 面议 (Negotiable) - 避免过多的细节；保持他们的灵活性，以便团队可以调整要实施的故事数量。
- 有价值的 (Valuable) - 用户或客户从故事中获得一些价值。
- 估计 (Estimable) - 团队必须能够使用它们进行规划。
- 小的 (Small) - 大故事更难估计和计划。到迭代计划时，故事应该能够在迭代中进行设计、编码和测试。
- 可测试 (Testable) - 记录验收标准，或为故事完成的定义，这会导致测试用例。
为什么要使用用户故事？
- 保持自己表达商业价值
- 避免过早引入细节，因为这会妨碍设计选项并不恰当地将开发人员锁定在一个解决方案中
- 避免出现虚假的完整性和清晰度
- 获得足够小的块，以邀请积压工作中的协商和移动
- 将技术功能留给架构师、开发人员、测试人员等
用户故事的 3个 "C" s
Ron 的 3C 是这样的：卡片、对话、确认。现在让我们关注这三件事，看看在实践中创建用户故事的过程。
“卡片、对话、确认”；这个公式（捕捉了用户故事的组成部分：
卡片 (Card)
一种物理标记，为原本只是抽象的东西提供有形且持久的形式：
开始编写故事时，模板可以帮助确保您不会无意中开始编写技术任务：
作为<用户类型>，我想<功能>使<收益>
例子：
- 作为<消费者>，我希望<购物车功能> 使我<可以轻松在线购买商品>。
- 作为一名高管，我想生成一份报告来了解哪些部门需要提高他们的生产力。
在编写用户故事时尽量避免用户的通用角色。用户故事是关于与系统交互或实现某些价值或从系统中受益的所有角色。并非所有参与者都是最终用户。例如，角色可以是另一个系统或想要某些功能以购买您的产品但永远不会实际使用该产品的人。创建聚合角色（例如消费者）和专门角色（例如浏览器或常客）可能很有用。
在 团结 ，此模板应输入在“说明”字段的顶部。这为将在下面输入的细节和验收标准定下了基调。
对话” (Conversation)
对话是获取有关卡的更多详细信息所必需的。对话促进了敏捷团队之间的增量和持续协作，以围绕问题和潜在解决方案建立共识。
对话发生在项目期间的不同时间和地点，涉及软件产品的特定特性的不同人员之间：客户、用户、开发人员、测试人员；这种谈话主要是口头的，但最常以文件为补充；
“确认” (Confirmation)
确认是验收标准，它捕获基本需求并将其转换为测试标准，以便我们知道何时成功交付了用户故事。
- How to Manage User Stories with Story Map?
- Write SMART Goals & INVEST for User Stories
- Theme vs Epic vs User Story vs Task
- Who Create Product Backlog Items or User Stories in Scrum?
- What is Agile Estimation?
- What is Story Point in Agile? How to Estimate a User Story?
- User Story Splitting - Vertical Slice vs Horizontal Slice
