什么是用户故事？

传统瀑布模式下，往往先等产品经理完成了产品PRD文档，然后技术团队再根据这份PRD文档实施开发。
在千变万化的市场下，基于完整PRD的才进行开发的模式遇到了挑战，研发团队越重视小步快跑，快速迭代，灵活满足不断变化的环境。比如出现一下状况：

拆字理解，用户故事=用户+故事=人+故+事，通俗解释，就是什么人因什么原因做某事。提炼出来就是三个要素，who、why、what。用这3个要素组成最简单一句话的需求描述。

用户故事由三部分组成，简称3C原则：

卡片也称为用户故事卡，相信大家对于这个卡片很熟悉了，虽然大家未必按照这个格式写用户故事。但有些人心中把用户故事等同于用户故事卡 ，如果这样理解，就会理解片面了，卡片只是用户故事最明显的表现方式，它并不是最重要的。加上后面的沟通和确认才是完整的用户故事。

用户故事代表的是客户最原始的需求，它并不是记录大而全需求的地方。卡片承载的是用户需求故事，而需求细节则通过对话完成。
故事之所以是故事，它是用来讲的，不是用来写的。
比如一个卡片上代表一个用户故事，它不是需求的全部，而组织相关干系人进行细节讨论，探讨价值和场景，才是最重要的。
而对话往往不是一次性的，用户故事是一个需求源头，刚开始定义的时候可以对话，设计评审、技术评审，测试验收等环节都可以进行对话。也就要求我们，对用户故事进行维护更新和持续迭代。
虽然我们常说的对话以口头交流为主，但可以借助其它工具，比如业务流程图、UI高保真图等等，沟通的目的是我们对需求达成一致的理解和认知。

3.Confirmation (确认)
用户故事还包含“确认”部分，也就是我们所说的“DoD”，“完成的定义”。这个DoD是大家共同讨论出来的，是大家都愿意遵守的原则。
如果纸质版的卡片，确认部分就可以写在故事的背面，即满足了什么条件之下，这个用户故事才算被满足。

有了确认条件，技术团队则更明确要测试什么，产品团队则可以确认用户故事是否达到预期和验收标准。
注意，这里的DoD不仅仅是功能性的，也包括非功能性，这往往我们容易被忽略，比如易用性、性能等方面的要求。
当然确认条件不是不变的，如果要调整验收条件，也势必影响我们的范围和工期，可能也要调整我们的迭代计划。

一个好的故事要满足INVEST原则：

顾名思义，从字面上大家应该都理解是什么意思了，这6个特性就不一一细讲，用简单的一句话讲下这6个特性的好处。

讲了这么多用户故事的好处？那么它有不足吗？
如果你分解了很多用户故事，可能会发现它们是零散的，只见树叶不见森林，这个时候就要用户故事地图来把故事串联起来。
其次如果是大项目，则难以组织成千上万的故事，此时就需要结合额外的文档实现可追溯性。

本次分享到这里，有兴趣的读者可以阅读原书，附上电子书链接 《用户故事与敏捷方法》