全球电商巨头亚马逊的老板贝佐斯开会时，经常会在自己的座位旁边放一张空的椅子，然后问他的下属：这个椅子上坐的人就是我们的客户，今天我们提的方案，客户会如何反应？是他想要的吗？
贝佐斯身边的这张椅子我们可以理解为用户画像，而画像中用户需要完成的有价值的事就是用户故事，比如说：作为检修人员，我要读取工作日志，以便我可以定位量产时失败的问题，方便后续检修。
综上，我们看出用户故事的作用是，它能更有效地让团队成员理解客户的需求，迅速建立共识，做出对客户有价值的产品。
在软件开发和产品管理中，用户故事是对软件系统的一个或多个特征的非正式的自然语言描述。用户故事是敏捷软件开发中使用的工具，用于从最终用户的角度捕获软件功能的描述。用户故事描述了用户的类型，他们想要什么以及为什么。用户故事有助于创建需求的简化描述。
所以，作为价值驱动型的管理方式：敏捷管理，自然也会用到用户故事，来确认客户真正需求，达到项目的最高价值，我们一起来看看，用户故事在Scrum中的哪一个步骤。
一、Scrum中的用户故事
Scrum流程：
1、产品负责人PO，负责整理用户故事，形成左侧的产品待办列表；
2、发布计划会议，PO负责讲解用户故事，对其进行估算和排序，发布计划会议的产出就是制定这一期迭代要完成的故事列表即迭代计划；
3、迭代计划会议，项目团队对每一个故事进行任务分解，分解的标准是完成该故事的所有任务，每个任务都有明确的负责人，且完成工时的初估计；
4、每日站会，每天Scrum Master如今站立会议，团队成员回答昨天做了什么，今天计划做什么，遇到了什么问题；
5、演示会议，迭代结束之后，召开演示会议，受邀相关干系人参加，团队负责向大家展示本次迭代取得的成果，期间记录大家反馈，由PO整理，形成新的故事；
6、回顾会议，项目团队对本期迭代进行总结，发现不足，制定改进计划，改进计划到后续迭代中，以达到持续改进的效果；
由此可见用户故事几乎参与整个流程，那么我们怎么创建用户故事呢？
二、创建用户故事
用户故事包含什么？用户故事是从用户的角度来思考用户真正需要的功能。所以一个好的用户故事必须要包括以下三个要素：
角色，谁要使用这个功能；
活动，需要包含什么样的功能；
价值，这个功能给客户带来什么样的价值；
用户故事是用日常语言编写的，并从个人（谁）的角度以及他|她想要的原因（为什么）描述特定的目标（什么）。
在软件开发中，目标通常是新产品功能，个人是某种类型的最终用户，原因是用户在目标产品功能中看到的好处。
用户故事事例：
作为[客户]，我想要[购物车功能]，以便[我可以轻松地在线购买物品]；
作为[经理]，我想[生成报告]以便[我可以理解哪些部门需要更多资源]；
作为[客户]，我想[在物品到达时收到短信]以便[我可以马上去接你]；
在上面的例子中：
角色表示将与要实现的系统进行交互以实现目标的个人、系统、子系统或任何其他实体，他|她将通过与系统交互获得价值。
活动表示用户可以通过与系统交互来实现的期望。
价值代表与系统交互背后的价值。
创建用户故事步骤：
1、识别项目干系人；
2、识别谁将使用该产品；
3、和干系人协作，写下产品将需要达成的需求，并用之前所提到的格式去创建你的用户故事。
三、用户故事常见问题
用户故事分解到体积程度？这就要提到INVEST方法。
实施这个方法时，用户故事应该是：
Independent独立的，在绝大多数情况下，一则故事所描述的特性不依赖其他故事；
Negotiable可讨论的，不需要太过详尽，为细节留出讨论和补充的余地；
Valuable有价值的，故事是为了给客户展现产品价值。故事描述的是特性，而不是一个单线程的从开工到结束的用户任务。故事用的是客户的语言，并且解释起来简单明了。使用该产品或系统的人群都能理解这则故事。
Estimable可估计的，故事是描述性的、准确的以及简练的，以便于开发者能够大体估算创建用户故事中的功能所必需的工作量；
Smal合适的小，计划和精确估算较小的用户故事会更加轻松。优秀的经验法则告诉我们，一个用户故事所占用开发团队一名成员的时间，不应超过兑现阶段时长的一半；
Testable可测试的，你可以轻松验证用户故事，并且能得到明确的结果。
用户故事编写注意事项：
不要将需求文档转成用户故事，不要用需求文档中的信息填充用户故事，从表面上看，写用户故事的工作就是把需求文档换一个格式，在研发团队把需求文档转成一堆用户故事的同时，业务方还要求同时继续写需求文档，敏捷不只在项目团队中，还包括业务和审计层，大家要保持统一的思想；
不要只在迭代开始前写故事，马上就要开发下个迭代了，Product Backlog里还没有东西呢，用户故事一顿狂赶，足足一个迭代的用户故事。用户故事应该是持续在项目中的每个过程中，这样迭代会议中，才不至于Product Backlog空空如也；
所有故事都要放在Product Backlog中，防止遗漏，把所有要做的东西都放到Product Backlog中，不管是短期要做的，还是很久以后要做的，都放进去，只写一句话标题，不填写详细内容，将需求池作为需求的唯一来源，防止疏漏；
ProductBacklog中故事的相对优先级会动态调整，看看ProductBacklog顶端大概1-2个迭代的数量，根据业务的要求进行用户故事编写，要求事情描述清晰详细，再根据优先级进行排序。
总结一下，用户故事最根本的作用，就是让我们站在用户的角度，实现该有的价值，用的过程中谨记价值这个词。
