用户故事
用户故事卡片的三个步骤：
1.Card，把客户描述的需求记录在卡片上（可能并不是最终需求）
2.Conversation，在对话中细化卡片内容和需求细节
3.Confirmation，确认最终的卡片内容
当故事的细节过多时，可以用另外的故事来描述，多个小故事远远胜于一个庞大的故事。
故事卡片的背面可以写上AC（acceptance criteria）
客户团队（软件客户和最终用户）需要（被期望）积极地参与到编写用户故事的环节中。因为他们可以对故事的优先级进行排列，并且他们作为产品的主要构想者，很适合描述产品的行为。甚至可以参与定义测试场景。
发布和迭代
客户团队和开发人员一起选择迭代长度，可能是1-4周时间。在每个迭代结束时，需要能够发布完全可用的软件子集（即某一部分功能模块）。
一旦确定迭代长度之后，开发就可以开始估计开发速度（即velocity速率，每个迭代周期可以做的事情的量）。第一次的速率估计也许是错误的，但是可以在一个迭代完成之后进行修正。每个迭代周期的任务量不应该超过估计的速率。
任务量通过故事点（story point）来衡量。
进行发布规划时需要考虑故事优先级，客户团队在排列优先级时需要考虑如下因素：
1. 大部分用户和客户对特定特性的渴望程度
2. 小部分重要用户和客户对特定特性的渴望程度
3. 故事之间的关系，比如互补关系的故事（例如“放大”和“缩小”）
验收测试
验收测试用来验证实现的用户故事是否符合客户团队的期望。
测试应该尽早开始编写，以便客户团队与开发人员沟通假设和预期，验证理解的准确性，也便于开发人员自测。
验收测试样例：
用Visa信用卡、MasterCard卡测试支付功能
用银联卡测试支付功能
用过期卡测试支付功能
用不同金额测试支付功能（包括超出信用卡额度的金额）
...
为什么要用用户故事而不是需求文档？
用户故事情调对话交流而不是书面沟通
用户故事可以同时被业务人员和开发人员所理解
用户故事的大小适合于做计划
用户故事适用于迭代开发
用户故事鼓励推迟细节设计，直到在不断的交流中让需求细节更加清晰
用户故事可以迭代，比如在最开始写下了一个巨大的低优先级的史诗故事（epic），当开发进行到一定程度，需要准备把这个故事加入系统之后，再来提炼它，用一系列更小更具体的用户故事来代替这个史诗故事。
