1. Questions
   1. 发布规划
      1. 高风险的故事应该排高优先级么？
      2. 什么是故事点的conversion rate？
      3. 为什么在确定优先级前应该先估点？
      4. 为什么不要过早调整发布计划？
   2. 迭代
      1. 为什么要有iteration kickoff？
      2. 为什么用户故事更加适合做迭代？
      3. 为什么在iteration中要对故事进行任务划分？
      4. IPM是干什么的？
   3. 用户故事
      1. 为什么白纸黑字的需求文档也不精确？
      2. 需求对话相对于需求文档有哪些优势？
      3. 为什么要切分成“完整“的故事？
      4. 为什么要由客户编写？
      5. 为什么不能引出或捕捉故事？
      6. 和瀑布式需求分析的区别在哪里？
      7. 与特性列表项目，用户故事有哪些优势？
   4. 物理卡片
      1. 为什么要使用卡片？如果卡片太小不够写怎么办？
      2. 为什么放弃软件管理工具，而使用物理墙？
   5. 验收测试
      1. ”软件应该易于使用“可以测试么？
      2. 为什么写在卡背面的验收测试不需要太详细？
   6. 估计
      1. 为什么使用Fibonacci来估计故事点数？
      2. 为什么推荐使用故事复杂度来估计？
      3. 为什么要对故事进行三角测量？
      4. 为什么不应该改变已完成迭代中故事的估点？
      5. 为什么不能计入部分完成的故事点？
2. User Story
   1. 编写故事
      1. Independent
      2. Negotiable
      3. Valuable
      4. Estimatable
      5. Small
      6. Testable
   2. 用户角色建模
      1. 头脑风暴
         1. 系统角色
      2. 整理角色
      3. 整合角色
      4. 提炼角色
      5. 为重要角色建立虚拟人物
   3. 收集故事
      1. 用户访谈
      2. 问卷调查
      3. 观察
      4. 故事编写工作坊
   4. 与用户代理合作
      1. 各类用户代理
      2. 使用多个用户代理
      3. 分析竞争产品
      4. 尽早发布软件来获取用户反馈
   5. 验收测试
      1. 在客户团队和开发团队讨论中充实故事细节
      2. 在开始写代码之前写好验收测试
      3. 确认故事是否被完整实现的基本标准
      4. 从用户和客户的角度去测试软件
   6. 优秀用户故事准则
      1. 从用户目标出发
      2. 切蛋糕
      3. 封闭的故事
      4. 约束卡
      5. 故事生命周期中的规模变化
      6. 不要尽早涉及用户界面
      7. 有些需求不是故事
      8. 在故事里包含用户角色
      9. 由客户编写故事
      10. 不要忘记故事意图
3. Estimate and plan
   1. 估算用户故事
      1. 故事点
         1. 理想天
         2. 故事复杂度
      2. 团队估算
      3. 由谁来估？
      4. 估算应该包括什么？
      5. 三角测量
   2. 发布计划
      1. 发布时间
      2. 交付哪些功能？
      3. 排列优先级
      4. 高风险故事
      5. 初始速率
      6. 制定发布计划
   3. 迭代计划
      1. 讨论故事
      2. 分解任务
   4. 测量并监控速率
      1. 速率图
      2. 累计故事点图
      3. 迭代燃尽图
      4. 迭代中的燃尽图
      5. 故事缺陷数
4. 经常讨论的问题
   1. 故事不是什么？
      1. 故事不是IEEE830
      2. 故事不是用例
      3. 故事不是交互设计场景
   2. 用户故事优势
      1. 强调口头沟通
      2. 人人都可以理解
      3. 大小适合做计划，做迭代开发
      4. 鼓励延迟细节
      5. 支持随机应变的开发
      6. 鼓励参与性设计
      7. 传播隐性知识
   3. 用户故事不良征兆
      1. 故事太小
      2. 故事相互依赖
      3. 镀金
      4. 细节太多
      5. 过早考虑用户界面细节
      6. 想得太远
      7. 故事划分太过频繁
      8. 客户很难为故事安排优先级
      9. 客户不愿承担责任
   4. 其它话题
      1. 非功能性需求
      2. 纸质还是软件？
      3. 用户故事和用户界面
5. 概述
   1. 软件需求是一个沟通问题
      1. 客户和开发团队要协同工作
      2. 把各个决策分散在项目过程中
   2. 什么是用户故事 （3C）
      1. 一份书面的故事描述 （Card）
      2. 有关故事的对话 （Conversation）
      3. 测试 （Confirmation）
   3. 客户团队
      1. 测试人员
      2. 产品经理
      3. 实际用户
      4. 交互设计师，业务分析师等