本篇重点介绍用户故事与敏捷代码中第一部分的其余篇章。这一部分着重强调了如何写出一个好的用户故事，以及如何捕捉到这些故事。当你在搜集故事的时候，需要对预期的发布进行展望并开始写下容易发现的故事。然后要是用多种方式发现用户故事，通过开放式，与背景无关的提问更容易获得有用的答案。
在与用户代理合作这一篇章中，我们要履行开发人员的职责，找到合理的用户代理，在物色合适的客户的时候，了解不同类型的用户代理的想法和背景如何影响交互。
当然了，写完一个完整的用户故事之后，我们要做到即使的用户故事验收测试。验收测试中可以记录我们在呵客户讨论的时候一些相关的细节要求（这一点就要开发人员有钱打的交流能力，引导可户一点一点对我们放下戒心，坦诚相待。并主动积极配合我们的合作找到用户故事中的细节点）因此，验收测试的时候最好由客户完成。
那么，一个优秀的用户准则又是什么呢？这个时候就要开发人员自己定义规则，不能让故事过早的涉及用户界面，而在编写故事过程中，创建约束卡，并及时和用户交流。
同时，我还了解到，在故事里包括用户角色 如果项目团队已经识别出用户角色，那么在编写故事时就要使用它们。比如用“求职者”来代替“用户”会更准确些。 一种将角色融入故事的模板：我作为（角色），想要（功能），以此（商业价值） 只为一个用户编写 当故事只为单一用户编写时，故事的可读性是最强的。 以主动语态编写 要写成“求职者可以发布简历”，而不是“简历可以被求职者发布” 由客户编写 向故事卡编号说“不” 给故事卡编号会增加无谓的流程，并导致我们去抽象的讨论需要形象化的功能。 不要忘记意图 故事卡的主要目的是用来提醒开发人员和客户团队对功能进行讨论的。既然仅仅是一个提醒，就要保持它的简洁性。加入必要的细节，以便联想到继续对话的切入点，但不要加入太多细节并以此取代对话。