软件需求总会发生变化。为了应对这些变化，敏捷方法没有一个独立的需求工程活动，而是将需求抽取与开发集成到一起。为了使之更容易，提出了"用户故事"的思想，其中每个用户故事是一个系统用户可能经历的使用场景。
系统客户应当尽可能地与开发团队紧密工作，并且与其他团队成员一起讨论这些场景。他们一起开发一种"故事卡片"，其中简要描述了一个包含客户需要的故事。接着开发团队计划在软件的后面某个发布中实现该场景。作为例子，描述了某系统的一个故事卡片。这是一个给病人开药物处方的场景的简短描述。

一个"开药物处方"的用户故事

用户故事可以用于规划系统迭代。一旦故事卡片已经开发好了，开发团队将其分解为任务并且预计实现每个任务所需的工作量和资源。这通常包括与客户讨论以精化需求。

"开药物处方"的任务卡片例子

接着，客户确定这些故事的实现优先级，选取哪些可以立即使用，以提供有用的业务支持的故事。其目的是识别可以在大约两周之内实现的有用的功能，到时系统的下一个发布可以被交付给客户。
当然，如果需求发生变化，那么未实现的故事会发生变化或者被抛弃。如果某个已经交付的系统需要变更，那么需要开发新的故事卡片，并且客户再次决定这些变化是否应当比新功能具有更高的优先级。
这里可以参考使用"用户故事地图"，便于组织和管理需求。

用户故事的思想很强大，人们发现与传统的需求文档或用况相比，使用这些故事要容易很多。用户故事在让用户参与初始开发之前的需求抽取活动并提出需求等方面很有帮助。
用户故事的主要问题是完整性。很难判断是否已经开发了足够的用户故事以覆盖一个系统所有的重要需求。判断单个故事是否正确描述了一个活动也不容易。有经验的用户经常很熟悉自己的工作，以至于会在描述时遗漏一些东西。