第一章 概述

1、什么是用户故事

Card conversation confirmation

2、用户故事的细节，可以用更小的用户故事体现

如何拆分用户故事

3、必须多长时间完成

记录客户的期望

4、客户团队

测试人员、产品经理、用户和UX

5、用户故事使用的过程

6、规划发布和迭代

参考迭代速率

7、什么是验收测试

验证用户故事是否符合客户团队的期望

测试前移可以推动团队沟通

8、为什么要用用户故事

用户故事由客户团队编写，可以同时被客户和开发理解

用户故事的大小适合迭代开发和计划

用户故事鼓励推迟考虑细节：在不确定是否真正需要某个新特性时，可以不花过多时间来考虑它。

第4章 搜集故事

敏捷项目承认没有一种理想的方法可以在一个单一阶段获取到所有的用户故事

方法：

1、用户访谈：采用开放性的问题和背景无关的问题，避免对用户的引导

2、问卷调查：收集已有故事的相关信息，但属于单向沟通，且时间滞后

3、观察：在现场观察用户如何使用

4、故事编写工作坊：快速编写大量故事，先考虑一种场景的深度，不判定是否编写正确，重点在数量而不是质量，可以先不排优先级。

第5章 与用户代理合作

在无法接触真实用户的情况下，我们需要求助于用户代理，每一类用户代理都有需要注意的问题：

用户的经理

开发经理

销售人员

领域专家

以前的用户

客户

培训师&技术支持

业务分析师

避免用户代理问题的解决方案：

使用多个用户代理

尽早发布产品，打开与用户沟通的途径

尽可能让真实用户加入客户团队

第6、7章 用户故事验收测试

1、编写封闭的故事

2、用约束卡来描述非功能需求

3、用户故事不要过多描述界面细节

4、包括用户角色，使用我作为，想要，以此 三段式来描述

5、只为一个用户编写，问题会更清晰

6、以主动语态编写

7、故事卡的主要目的是用来提醒开发人员和客户团队对功能进行讨论。保持简洁性，加入需要的细节，联想起对话的切入点。

第二部分 估算和计划

第8章 估算用户故事

三角测量：通过比较的方式，估算故事相对关系

团队速率：平均一个迭代内可以完成的故事点数

团队间的故事点不一致

第9章 发布计划

1、排优先级的方式

MoSCoW

如果遇到混合优先级的情况，将故事进行拆分

敏捷支持先做最有价值的部分，而不是高风险故事

排优先级时，要考虑技术架构的实现

2、选择迭代长度

1-4周，尽可能短

3、初始速率

历史值；执行一轮初始迭代的速率；猜测（理想人天的1/3到一半）

第11章 测量并监控速率

1、迭代速率只包括迭代完成的故事点数，部分完成的不计算。

2、关注每个迭代，计划故事点与实际故事点的偏差

3、迭代燃尽图记录每个迭代剩余的故事点数，每日燃尽图记录迭代每天剩余的小时数

第12章 用户故事不是什么

1、用户故事与需求说明书的区别：

需求说明书以系统实现为目的，用户故事以用户价值为目的

需求说明书成本难以估算

2、用户故事与用例的区别

用例的范围更广；用例的生命周期更长；目的不同

3、用户故事与交互场景的关系

交互场景更细节，更具体

第13章 用户故事的优势

促使我们重视口头交流

开发者和用户都能理解用户故事

鼓励延迟细节

不足：缺少额外文档，故事之间的关系不容易体现

第14章 用户故事不良症兆

1、故事太小

共享实现或者工作量不大，可以合并

2、故事互相依赖

3、避免开发人员实现不必要的功能

4、细节太多

过于重视文档，忽略口头交流

5、避免描述界面

6、很难排优先级

对故事进行拆分

第16章 其他话题

1、处理非功能需求

约束卡