1-规划发布和迭代
大部分用户和客户对特定特性的渴望程度
小部分重要用户和客户对特定特性的渴望程度
故事之间的关系。例如：某些故事优先级不高单与高优先级故事产生不可忽略的联系
6-用户故事验收测试
在开发之前写测试
理想状态在组织用户故事时候就开始记录和明确细节，根据用户故事写出测试
测试是过程的一部分
以用户角度出发做测试，程序通过验证不代表使用通过验证，产品经理和测试共同负责详细的测试。产品=目标、测试=怀疑，形成完整测试
持续测试
7-优秀用户故事准则
从目标开始
大型软件角色众多，最好的办法是考虑每种角色的使用目的
分割大故事
大的用户故事应切割成几个较小的故事
例：-求职者可以发布简历<br>1、求职者可以提交简历，简历上只包括诸如名字、地址和教育背景这样的基本信息<br>2、求职者可以提交简历，简历上可以包括雇主想看的所有信息。
编写封闭的故事
是指那种一个有意义的目标实现而结束的故事
卡片约束
标注为约束的卡片帮助确定一些边际，同时可以帮助测试
根据实现时间来确定故事规模
不要过早涉及用户界面
有些需求不是故事
在故事中包含用户角色
我作为（角色），想要（功能），以此（商业价值）
只为一个用户编写
由客户编写
理想情况由客户编写故事，并且排列优先级（权重）
不要编号
不要脱离目的
故事卡的主要目的是用来提醒开发以及客户团队对功能进行讨论，仅作为提醒，尽量保持简洁，加入少量细节即可
8-估算用户故事
特点
无论什么时候获得有关故事的新信息，都允许我们改变之前的想法
故事无论长短都适用
为工作进展和剩余工作提供有用信息
不太精准的估算也不会有问题
可以他用来制定发布计划
故事点
以故事点为单位时间估算，故事点数量x单位时间=粗略估算
以团队估算
团队根据故事点给出时间段，团队估算更有意义
估算
使用卡片团队中每个人都给出估算时间，并发表估算意见，相互激发想法和解决方案对时间估算更有帮助
三角测量
用来验证故事点的颗粒度
就是把对应时间单位的故事点放在一起，看看相同时间的估算是否一致
使用故事点
如果项目一共有300个故事点，每周计划完成30个故事点，那需要10周（10个迭代）才能完成开发<br>如果第一轮迭代（第一周）完成了50个故事点，那他们需要6轮迭代才能完成项目，那就应该把开发速率调整为50个故事点，6论迭代完成项目，反之亦然<br>
尽量对齐颗粒度，减少开发速率的起伏
第一轮故事点保持独立，不受用户界面细节的影响
提醒
不同团队对相同故事点的估算不同
大故事分解成小故事后，小故事的故事点总和不需要和大故事的相同
类似小故事里的任务同理
9-发布计划
发布时间
一个时间范围，而不是时间点
但确定的时间点会提高效率和成功率，会折损发布内容
包含功能
DSDM
MoSCoW（莫斯科规则）
这次不会有-Won't have this time
客户期望有-后续版本加
排列故事优先级
不能如期完成的（例如有预期性能特点或全新算法的）
推迟实现一个故事时对其他故事的影响
故事对广泛用户或客户的重要性
故事对少部分重要用户或客户的重要性
故事与其他故事的相关性（连接性）（比如放大是高优先级，同时缩小并不是高优先级，但他们是同时存在的）
成本会改变优先级
混合优先级
同一个故事里会有细节的优先级不同，可以按照混合优先级排列
高风险故事
本着优先支持最有价值的部分，但是根据用户期望的高优先级也会包含高风险的故事
根据架构需要安排优先级
基础或非功能的需求会因为架构的约束而影响
选择迭代周期
根据故事点预计工期
初始速率
创建发布计划
故事卡钉墙上（公开）用于展示迭代
对于记录在电子表格重的故事，根据迭代进行排序，并分割每论迭代
输出详情给需要了解细节的利益相关人员
可以用甘特图给不需要了解细节的利益相关人员
10-迭代计划
迭代计划会
从故事中分解出任务
开发人员承担每个任务的职责
讨论所有故事，接受任务后，开发单独估计各自承担的任务，确保不做过于乐观的承诺
13-用户故事的优势
用户故事强调口头沟通
一份共享的文档并不是已经达成共识
人人可以理解用户故事
用户故事更简洁明了的让人理解和沟通，并且加强了记忆
用户故事的大小适合做计划
相对IEEE830续期列表太过细节，内容量大，而交互设计场景和用例又有些宽泛，优先级排布意义不大，用户故事可以控制大小，可以方便的发布规划、开发、测试
用户故事适合与迭代开发
IEEE830 太细，但很难做到完美
用户故事鼓励延迟细节
由粗略的故事可能衍生更多的细节，非常适合敏捷开发，开发时才需要更多细节填补
用户故事支持随机应变的开发
用户、客户通常不会准确的知道自己的实际需求
即便软件开发者知道所有的需求，很多随开发进展变得清晰<br>
就算假设所有的细节可以在前面弄清楚，人们也没有能力理解这么多的细节
就算理解了这么多的细节，产品和项目也有可能变更
是人都会犯错
用户故事鼓励参与性设计
让用户从最初的设计就参与进来，用户故事中完全没有专业术语，完全可以
用户故事传播隐性知识
面对面的和用户沟通促进了团队的隐性知识积累，越频繁的沟通交流越有积累
用户故事的不足
大量的系复杂——尽量使用角色去淡化关系，
大量的用户故事的大项目会使用户故事之间的关系复杂，尽量用角色来淡化故事关系的复杂性，而且要保障用户故事不要过于细化
开发过程中需要文档记录积累以延续，要兼顾文档的存留，使用在线文档管理以故事为骨架，以测试文档为肉可能会解决这个问题
超大团队的层级信息流通性，需要做好平衡
14-用户故事不良征兆
故事互相依赖
划分不恰当或故事太小会产生必须做完某事再做某事的现象，，要把有依赖关系的故事合并成一个故事
镀金
开发人员主观添加超过用户需求的功能
自我约束减少镀金
细节太多
花太多时间写故事、记录，减少记录过多细节
避免过多记录，增加口头交流
过早考虑用户界面细节
优先看用户目标，减少界面细节的定义
想的太远
故事划分太过频繁
故事 太大以至于一轮迭代完，或者客户只希望下轮迭代完成高优先级的子故事
过于频繁的划分故事说明出现了问题，考虑剩余的故事找出真正的需求
客户很难为故事安排优先级
安排优先级太困难
可能是故事太大，很难安排优先级
也可能是故事不够清晰，需要重写
客户不愿意写用户故事，也不愿意为故事安排优先级
15-Scrum 与用户故事
Scrum 是迭代和递增
Scrum每30天一轮迭代称为sprint
Scrum Master 相当于传统的项目经理，但更像是领导和组织者，而不是经理
一般一个Scrum团队包括4-7个开发人员
产品backlog是一个待开发的功能需求列表，要么还没实现到产品中，要么还没计划到当前的sprint<br>
sprint backlog是一个团队承诺在当前sprint完成的任务列表
在极限编程里面的客户角色，在scrum中称为产品负责人
产品负责人给产品backlog 排列优先级
在sprint的开始，团队从产品backlog中选下一个Spring要完成的任务
在每日scrum简会中，每个团队成员需要回答三个问题，我昨天完成了什么，我今天要做什么？我有哪些问题？
每个sprint都要完成一部分可以潜在交付的产品功能增量
在sprint 结束时，团队在sprint评审会上演示所完成的功能
