一期内容回顾，如果希望了解可以点击页首的目录。
之一：用户故事有些比较主要（直接体现用户价值），有些相对次要，应区别对待；其中“业务操作”最适合写成。
之二：利用功能点中业务数据（文件）+业务操作形成最主要的用户故事框架，非常方便产品经理和用户理解产品功能
之三：利用快速功能点可以迅速估算这些用户故事的完成工作量，即功能点 = 业务数据 × 7 + 业务操作 × 4 。
之四：功能点数 / 生产率 = 估算工作量，其中引用了国际和中国OA的参数。
之五：总结。
“为什么一期说了半天，不像是谈用户故事，更像是功能点？”因为用户故事和功能点都是对需求进行条目化、描述的方法，而后者更利于在前期进行估算，估算的精度也非常好，所以建议大家在写主要的用户故事的时候，遵从功能点的定义。
而二期，则主要是说进入开发阶段后，那些微小的开发任务如何描述和管理，以及众多大小各异的用户故事该如何组织。
二期内容：
1. 回顾一期
2. 有哪些种类的用户故事？哪些决定了产品架构？哪些是细枝末节？不方便写成“作为一个……可以……以便……”的故事该如何描述？
3. 用户故事组织结构：如何“摆放”用户故事才能不失大局？如何才能“一眼看到”10人年开发的成果？
4. 用户故事跟进开发：用户故事后来哪里去了？用例、MVC这些设计实现元素与用户故事这个需求管理元素有什么对应关系？
鉴于内容很多，而且多数不是传统的敏捷开发考虑的问题，而是首次被实践和提出来的解决方案，因此视现场的进度和互动，可能要分3期才能讲完。
本话题中所涉及的产品需求管理理念，在火星人敏捷开发免费工具中已经实现，欢迎同时关注本博客中未来关于火星人的文章。
位置：
直播现场 QQ群：190375042 PMBar项目实践群，需要提交简历，欢迎项目经理以上人员加入，加入报名： http://www.pmbar.net/read.php?tid=1406
转播现场：博客左侧四个QQ群均进行图文转播，所问问题也会被反向转播到直播现场，请根据自己所处地区加入相应的QQ群。