用户故事是敏捷开发流程中的一个工具，使用用户故事来收集、整理、分析、跟踪需求。
本书比较详细地解说用户故事的用法。以下是书中的一些观点信息的摘抄：
1：如果故事太大以致无法在一轮迭代中完成，可以考虑把它分成两个或更多的小故事；
2：用户故事是很有意思的，因为他们强调口头沟通，客户和开发人员都可以理解，可以用于进行迭代计划，在迭代开发过程中能很好地工作，因为使用用户故事事实上鼓励推迟细节；
3：优秀的故事应该具备以下特点：独立的，可讨论的，对用户或客户有价值的，可估计的，小的，可测试的；
4：理想情况下，故事之间是独立的。有时很难做到这一点，但我们要尽量实现这一目标；
5：故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事；
6：给故事加上注释的最好的方法是给它编写测试用例；
7：能够引出及捕获需求这一想法是错误的。它有两个有问题的假设：用户知道所有的需求；需求一旦被捕捉，就锁定，不再改变；(p45)
8：使用开放式、与背景无关的提问更容易获得有用的答案，例如，“告诉我你想怎么搜索工作？”就胜于“你要通过职位名称来搜索工作吗？”（p45）
9：让开发经理担任用户代理，是最坏的选择之一，除非你们开发的软件就是给开发经理用的；（p48）
10：让销售人员充当用户代理是危险的，这会让大家对正在开发的产品没有一个全面的蓝图。对销售人员来说，最重要的故事是那些如果没有实现就会导致他丢单的故事；（p49）
11：让领域专家来担任用户代理的另一个潜在问题是，最终开发出的软件可能仅仅针对那些与领域专家有类似水平的用户；（p50）
12：如果用培训师充当用户代理，你的系统最终只能成为一个容易培训的系统。类似的，如果你让技术支持来充当用户代理，那么你的系统最终只是使得支持工作变得较为容易；（p52）
13：让客户，而不是开发人员，编写故事；（p69）
14：故事与用例之间最明显的区别是它们的范围。两者的大小都以交付商业价值为目标，但故事的范围更小，因为我们对它们的大小有限制，以便用于安排工作；（p112）
15：相信我们能够写下一个系统的所有需求，然后从上往下想出解决方案，这向来就是一个美丽的陷阱。约20年前，Parnas及Clements（1986）已经告诉我们根本不可能有这样的好事儿。（p124）