用户故事相比其他需求文档，更便于读者理解，大小也适合制定开发计划，适合迭代开发。用户故事鼓励延迟细节，支持开发过程中的随机应变，鼓励参与性设计。
首先讨论故事，客户从最高优先级的故事开始读给开发人员听，开发人员提问，直到开发人员充分理解故事，能够将故事拆分为任务。但需要注意没有必要理解故事的所有细节。然后我们就开始分解任务，将故事拆分为任务可以让故事被多个开发人员并发处理，并且故事是对用户或者客户有价值的功能描述，并不是开发人员的待办事项，因此分解后更能让开发人员了解具体的工作。接下就需要分担职责，每个任务最好只关联一个人，确保在迭代期间完成任务是他的职责。但同时确保在迭代期间完成任务又是所有团队人员的职责，所以如果在一个任务无法完成时，需要考虑作出调整。最后就需要开发人员作出完成任务的承诺，确保一个迭代的任务在迭代周期内能够顺利完成。在软件一部分已经完成时，用户可以进行验收测试。这时作者模拟了一个场景来为我们生动形象的表达测试的步骤。首先我们可以测试一些系统的基本功能项，来了解系统是否完成了这些基本项目。再测试限制条件。
阅读完本书后，我大体了解了有关于用户故事的一些知识。语句在书写在书面上时，对于表达像软件这么复杂的需求是比较有限的。由于他们可能被误解，所以需要开发人员客户和用户频繁沟通。用户故事提供了一个方法，让我们可以不断的重温事件场景，写下不会遗忘的且可以估算和计划的。