第一章：概览
1.故事卡包含对用户或者客户价值的功能的简短描述，是故事的课件部分，但客户团队和开发人员关于故事的对话更重要，有任务团队编写，因为他们最了解如何表达需要实现的需求。
2.按照故事对客户的价值来安排故事的优先级顺序。
3.速率是开发人员可以在一轮迭代中完成的工作量。
4.放入一轮迭代的故事估计综合不能超过实现开发人员预计的速率。
5.故事太大，无法一轮迭代完成，可以分成几个小故事。
6.验收测试用于验证实现的故事是否开发成符合客户团队的设想。
7.用户故事是很有意义的。
第二章：编写故事
1.理想状态下，故事之间是独立的。有时很难做到，我们可以拿一个故事来实现。
2.故事细节有用户和开发人员讨论得出。
3.让用户编写故事。
4.注释不能太多。
5.故事太大就拆分，太小就合并。
6.故事应该是可以测试的。
第三章：用户角色建模
1.考虑用户类型要避免单一，要识别与软件交互的不同用户角色。
2.有时用代表人物俩描述会很有帮助，极端人物也可能会有帮助。
第四章：搜集故事
1.能有引出及捕捉需求这一想法是错误的。
2.拖网捕鱼的比喻是非常有用的。
3.及时敏捷流程支持需求的后期涌现，也需要对预期的发布进行展望并开始写下容易发现的故事。
4.使用多种方式发现用户故事。
5.通过开放式、与背景无关的提问更容易获得有用的答案。
第五章：与用户代理合作
要找到合理用户代理。
开发人员职责
物色合适的客户，了解不同类型的用户代理的想法和背景是如何影响交互的。
客户团队职责
如果不是软件的用户，就要了解自己属于哪类用户代理。
第六章：用户故事验收测试
验收测试可以记录客户和开发人员讨论的很多细节，几率了有关故事的一些假设。
验收测试应由客户来写。
验收测试应在程序员写代码之前写好。
第七章：优秀用户故事准则
创建约束卡，
不要让故事过早设计用户界面。
用主动鱼台编写故事。
为单个用户编写故事。
让客户编写故事。