用户故事应从始至终贯彻于整个的开发流程。首先产品负责人根据收集来的需求编写用户故事，放入产品Backlog中。在Sprint计划会中，团队成员讨论其中的一些优先级高的用户故事，细化故事细节，确定验收标准，使用Planning Poker(计划扑克)估算故事点。然后将故事分成一些小的任务，并估算工时。最后，将故事放入Sprint Backlog中，并按照优先级进行排序。
什么是用户故事？
用户故事描述了对用户，系统或软件购买者有价值的功能。用户故事由以下三个方面组成：
1.一份书面的故事描述，用来做计划和作为提示。
2.有关故事的对话，用于具体化故事细节。
3.测试，用于表达和编档故事细节且可用于确定故事何时完成。
用户故事的意义在于强调口头交流，你和开发人员都可以理解，可以用于进行迭代的计划，在迭代的过程中能够很好的工作，而且它可鼓励推迟细节。
用户故事的六个特征
独立的，
可讨论的，
对用户或客户有价值的，
可估计的，
小的，
可测试的。
用户故事中用户角色的建模步骤
通过头脑风暴，列出初始的用户角色集合；
整理最初的角色集合；
整合角色
提炼角色
用户故事验收测试
测试是一个两步流程：
第一：将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录在故事卡的背面；
第二：将测试要点变成全面的测试，这些测试可以用来演示故事已正确、完整地实现。
这里确认下了用户故事的验收标准，可使用TDD开发模式，提高代码质量，真正的做到质量内检。
优秀用户故事准则
1.从目标故事开始，可衍生出新的故事；
2.切蛋糕：当面临一个大的故事时，需要分解成小的故事，每个小故事都提供某种程度的完整(end-to-end)功能；
3.编写封闭的故事，独立可形成闭环；
4.卡片约束：设定必须要遵守但不需要直接实现的故事；
5.根据实现时间来确定故事规模；
6.不要过早涉及用户界面；
7.有些需求并不是故事，找到需求适合的描述方法才是最重要的，如文档编写等；
8.在故事中包含用户故事：我作为（角色），想要（功能），以此（商业价值）
9.只为一个用户编写；
10.以主动语态编写；
11.由客户编写；
12.向故事卡编号说“不”；
13.不要忘记意图，故事卡仅仅是个提醒，要保持它的简洁性；
估算用户故事
估算故事的最好方法有如下特点：
1.无论什么时候获得用户故事的新信息，都允许我们改变之前的想法；
2.适用于史诗故事和小故事。
3.不需要花很多时间；
4.提供进度和剩余工作的有用信息；
5.不太精确的估算也不会有太大问题；
6.可以用来指定发布计划。
用故事点估算故事，故事点是故事复杂度，工作量或工期的相对估算。
应由团队估算故事，估算属于团队而不是个人。
通过和其他估算进行比较来进行三角测量。
团队是否使用结对编程对故事点估算没有影响。结对编程影响的是团队的速率，不是他们的估算。
迭代计划
迭代计划会议的一般内容如下：
1.讨论故事。
2.从故事中分解出任务。
3.开发人员承担每个任务的职责。
4.讨论过所有故事，并且接受所有任务后，开发人员单独估计他们承担的任务，以确保他们不会做出过于乐观的承诺。
测量并监控速率可透析一轮迭代中故事点完成速率对于后续迭代有指导意义
用户故事的优势
1.用户故事强调口头沟通；
2.人人都可以理解用户故事；
3.用户故事的大小适合做计划；
4.用户故事鼓励延迟细节；
5.用户故事支持随机应变的开发；
6.用户故事鼓励参与性设计；
7.用户故事传播隐形知识。
Scrum与用户故事
1.在Sprint计划会议中使用用户故事，产品的Backlog每一条都是一个用户故事，计划化的效率提高。
2.在Sprint评审会议中使用用户故事，可视化哪些工作已完成。
3.在每日Scrum简会中使用用户故事，确保整个团队关注余下的面向客户和最终用户的任务。
用户故事与敏捷开发相辅相成，用户故事可帮助团队更好的敏捷开发。用户故事将需求以卡片的形式记录展示，并与客户共同确认故事的优先级，在迭代的过程中，可视化故事完成进度看板。
