有那么多的处理需求的方法，为什么我们要选择用户故事？使用用户故事到底有哪些好处？
1.用户故事是需求源头，贯穿产品实现周期
需求从何而来，回归用户本身，如果一个需求用户故事都不能简洁明了表达出来，那么需求规格书和用例更加无法编写。
如果没有写用户故事，随着时间的推移，到了实施开发或测试环节，常听到团队一种声音，“为什么做这个需求”、“我也不知，产品是这样定的”，则难以追溯原来的用户原始需求。
另外一方面，用户故事来不但表达用户想要什么，更表达了功能的价值，当一个团队所做的事不知有何价值时，就会导致驱动力不足。
而用户故事，则把实施过程的设计阶段、开发阶段、测试阶段连接起来。通过细节的渐进明细，用户故事把需求设计敏捷化；通过定义了需求的优先级，制定迭代的版本目标，用户故事和开发连接起来；通过DoD验收标准的逐渐明细，用户故事和测试连接起来。
正是用户故事把设计、开发、测试都连接起来，贯穿整个产品实现周期，让整个团队以终为始做有价值的功能，明确知道给用户带来什么价值，不断带来成就感来形成内在驱动力。
2.用户故事更加容易理解
用户故事的好处是，业务人员和开发人员都能够理解。比如让业务人员看软件需求规格书，看到技术术语摸不着头脑；与此同时，让开发人员看到领域术语让也会无法适从。用户故事简洁明了，并且向用户展示价值，业务人员和开发人员理解起来都很容易。
组织成故事，增强人对事件的记忆，需求通过用户故事来展现以及进行讨论，这不但对回忆讨论清楚事件细节有帮助，而且对潜在暗示的事件情节也有用。
3.用户故事鼓励延迟细节
使用用户故事的一个优势就是鼓励团队延迟收集细节，我们可以先写一个具有目标层面及具有意义的用户故事，比如“求职者可以发布简历”，在这个故事对于后面开发进程变得重要的时候，我们才对这个故事进行细节补充。
因此，用户故事非常适合敏捷开发模式，具有时间限制的项目，团队可以快速地写出数十个用户故事，让大家对开发的系统具有一个系统性的认识，然后就能讨论高优先级的故事的细节并开始编码，这远比先写出完整的产品PRD文档再实施开发进展快速得多。
4.用户故事适用于迭代开发。
在开始编码之前，我不需要写出所有的用户故事，我可以先写出部分的用户故事，结合其相关设计就可以进行编码与测试，然后按照版本目标重复这个过程。写故事的时候，可以按照合适的颗粒度去写，正因为我们对用户故事本身有迭代，因此用户故事对迭代开发非常合适。
例如，我可能写出一个史诗的用户故事“用户可以撰写并且可以发送电子邮件”，这对于早期计划有用，但项目渐进明细，我可能切割成一打新的故事
- 用户可以撰写一个邮件消息
- 用户可以发送电子邮件
- 用户可以在邮件消息包括图片和附件
- 用户可以设定具体时间进行发送
如上面的用户故事，则可以进行规划迭代开发，1.0版本可以先完成邮件撰写和发送，后续的版本则不断持续升级。
5.用户故事鼓励参与式设计
像场景一样，用户故事引人入胜，把讨论的重点从系统特性转移到描绘用户使用系统目标的各个故事，让讨论更加有趣起来，讨论起来也非常便捷。
另一方面，用户故事完全没有技术术语和领域术语，开发人员和业务人员都容易理解，正是故事易懂、易读因此激发用户的积极性，成为软件设计的参与者。
6.用户故事传播隐性知识
用户故事的3C原则，卡片（Card）是表现方式，而更加强调人与人之间的交谈Conversatio，故事能够促进团队内的隐形知识，开发人员与业务人员沟通得越密切，越多的隐形知识能够得到传播和沟通。
