用户故事与敏捷方法第一章是对用户故事的概览。
首先第一个问题用户故事是什么？用户故事描述了对用户、系统或软件购买者有价值的功能。用户故事由三个方面组成，包括1 .一份书面的故事描述，用来做计划和作为提示。2.有关故事的对话，用于具体化故事细节。3.测试，用于表达和编档故事细节且可用于确定故事何时完成。
然后第二个问题细节，故事的细节可以用另外的用户故事来描述，多个小故事远远胜于一个庞大的故事。书上将大的故事成为史诗故事，那些史诗故事可以分为多个小故事。例如将“用户可以搜索工作”分为1.用户通过地区、薪水范围、职位、公司名和发布日期来搜索。2.用户可以查看搜索结果中的每个工作的信息。3.用户可以查看发布工作的公司的详细信息。但是故事并不一定要分解到可以覆盖到每个细节。一些细节可以让开发团队和客户讨论，换句话说要让这些细节变得重要时才被讨论。
第三个问题是用户期望，要将用户期望记录下来在纸质卡片的背面或者是电子文档的空白处。让开发人员了解客户的期望。客户团队是因为找不到专职人员排列工作的优先级，以及回到开发人员的问题而建立的，它理应包括满足用户需求的所有人，其中有测试人员，产品经理，实际用户，交互设计师。
第四个问题使用故事的过程是怎么样的？在传统的面向瀑布的模型中只有在开始和结束时参与。对于故事驱动的项目而言，客户和用户在整个过程都参与，他们在编写用户故事时承担非常活跃的角色，尤其是在团队极限编程时。编写用户故事的过程最好从考虑系统的用户类别开始，客户团队最好包括这些实际的客户类别，如果不能，则可以使用用户角色建模代替。然后开始写故事的初稿，初稿一般是在故事编写工作坊中写的，（用户故事可以在项目生命周期的任何时候写），大家充分发挥想象来写故事。写完故事初稿后，客户团队和开发人员一起选择迭代的长度。每轮迭代客户团队高度参与故事和测试。确定迭代长度后，开发人员会估计每轮迭代做的事情，然后估计发布计划。在迭代时把最高优先级的故事放在第一堆，然后依次进行，直到项目完成。（每轮迭代之前客户团队可以修订计划，用实际速率来代替估计速率，并进行修正。）
第五个问题规划发布和迭代，客户和开发人员都要参与发布和迭代，排列故事优先级时，应该坚持组织利益最大化，同时要听从技术人员的意见。
第六个问题验收测试。验收测试是用来验证用户故事是否符合客户团队的期望。测试应该尽早在迭代中编写，这样客户团队的假设和预期会更早与开发人员沟通。
通过第一章的阅读，我认识到，开发的过程用户参与非常的重要，用户故事在整个开发过程中起着主导作用，同时开发人员还要对用户的故事提出技术上的修正和指导。客户团队和开发人员在开发过程中不断修正方向最终才能完成任务。