用户故事（User Story）是从用户的角度对系统功能的描述。所以，又被称为使用者故事。
用户故事最重要的特点在於每一 个用户故事都是一个“可独立分配”的需求单位。要达到“可独立分配”，就要从“用户”如何使用系统来表达用户故事。这样才让你实现到一个能让用户交流，端到端（用户界面到后端）的功能单位。
在敏捷开发中，需求最终会被描述成User Story。开发人员依照用户故事中的描述估测完成所需要的时间，并指定该User Story的优先级。这样，最终，所有的User Story组成了Product Backlog。
在敏捷中，用户故事是最基本的设计单元，它是从用户的角度出发对功能的一段简要描述。啰嗦一下，用户故事是轻量级的需求描述。用户故事没有什么强制性的语法。但是，按照大致符合这样一个形式来考虑用户故事是比较有益的：
用户故事从用户的角度描述用户渴望得到的功能和实现的价值。一个好的用户故事包括三个基本要素：
角色：谁要使用这个功能。
活动：需要完成什么样的功能。
商业价值：为什么需要这个功能以及这个功能带来什么样的价值。
用户故事通常按照如下的格式来表达：
英文：
As a , I want to , so that .
中文：
作为一个<角色>, 我想要<活动>, 以便于<商业价值>
举例：
作为一个“网站管理员”，我想要“统计每天有多少人访问了我的网站”，以便于“我的赞助商了解我的网站会给他们带来什么收益。”
需要注意的是用户故事不能够使用技术语言来描述，要使用用户可以理解的业务语言来描述。
作为【用户的类型】，我希望可以【先这样做，然后那样做，就应该得到...的结果】以便【业务价值】。
例如：“作为购书者，我希望可以根据ISBN来找到一本书，以便能更快的找到正确的书。”
在做用户故事时，需要注意每个用户故事用的是用户的语言，它只描述一个功能（feature），而不要涉及设计或实现上的内容。
一般而言，每个用户故事的开发周期不要太长（1－5天），否则用户故事应当切分为多个子用户故事。
不需要一开始对所有的故事都进行详细的描述，但计划放在下一个sprint中的故事应该比较清楚。
在面对一个具体项目，不会把项目拆分成用户故事，就无法敏捷起来！真正的敏捷开发必须是基于用户故事的开发过程。
我们看到很多人在尝试敏捷时，只是简单地把项目的长周期拆分成短周期，这并不是真正的迭代，因为每个周期都没有可体验、可交付的东西，依然像瀑布一样在不断堆积半成品，这不是真的Scrum。
如果不是基于用户故事开发，测试驱动开发（TDD）和行为驱动开发（BDD）很难开展，因为缺乏具体用户场景的描述，很难写出具体、简明的测试用例，因而很难累积足够的自动化测试提高系统的可改性，内部质量、重构、持续优化便无从谈起。
如果不是基于用户故事开发，持续集成（CI）也意义不大，因为提交的代码并没有构成可交付的产品，其实并没有真的在集成。
用户故事和用户场景搭配起来使用，会起到更好的作用。用户故事反映了用户面对的问题
用户场景的描述更多，包含了更多的信息，比一个用户故事更长、更丰富。用户场景尽可能接近现实，用文字表达会说话的典型用户。
用户场景举例：比如：人们每次去超市买东西，都要排好长时间的队伍进行结算，特别麻烦。有的时候就会有人放弃结账，不买了，或者找到另外的超市购买，这样，对于超市来说，就会有损失。
那么针对这个用户场景，用户故事可以这么来写：作为一个消费者，我希望在超市买东西结账的时候，可以不用排那么长的队，我可以快速结账，以便节约出时间干些更重要的事。
每次的评审会议，其实也是对用户故事进行评审。
敏捷开发中的用户故事一定要重视，通过用户故事，形成用户故事地图，这样客户对整个产品就会有一个更直观的价值体验。
关于用户故事地图，有一本书写的挺好。
欢迎关注我们的公众号，在公众号回复“用户故事”，您将知道是哪本书。
