Murali Krishna告诉我们：

未能彻底明白用户故事的性质往往都是未能有效地转变到敏捷开发的重大问题。用户故事最重要的特点在於每一个用户故事都是一个“可独立分配”的需求（特徵）单位。要达到“可独立分配”，就要从“用户”如何使用系统来表达用户故事。这样才让你实现到一个能让用户交流，端到端（用户界面到后端）的功能单位。

Murali想的跟众多敏捷社区的人仕一样——用户故事是最好的选择，并引用Mike Cohn写的一篇文章Advantages of User Stories for Requirements。文中指出：

1. 写下故事描述，用作计划和提示
2. 故事的对话为故事细节
3. 以测试作为细节的记录，用来判断故事是否完成实现

然后比较了用户故事和另一个出名的需求收集技巧——用例：

因为故事中有一些跟用例或传统需求语句相同的特征，所以弄清故事和这些早期的需求技术之间的差异是很重要的。这些分别特显出用户故事的好处。用户故事强调说话沟通，文书语言往往很不仔细，亦不能保客户和开发人员所理解的都一样。例如，餐牌上这样写：“前菜有餐汤或者沙拉和面包”

这应该不难理解，但到底我可以选的是

餐汤或者 (沙拉和面包)

(餐汤或者沙拉) 和面包

我们都按著貌似准确的文字去办事，但实情往往不是如此。试比较一下餐牌上写的和侍应生亲口说：「先生想点餐汤还是沙拉？」更好的应该是，在点菜之前送一篮面包过来。

1. 用户故事和Backlog上的项目不能提供设计师工作所需要的内容脉络——用户在做什么时候情况下做这事情，这行动的内容前文后理，以及在这一刻的高层目标。
2. 用户故事和Backlog上的项目不能提供项目团队所需要的“完整性”——我发现开发队伍对项目估算的故事点随著工作开始以后不断增加，犹如无止境的一样。开发人员及项目赞助人也为此感到同样的沮丧。到底项目确确实实有多大呢？
3. 跟完整性有关的是，用户故事和Backlog上的项目不能提供一个合适的机制来考虑到未来工作的困难程度（原则上他们可以, 只是实际上他们不行）——我不断收到这样的投诉，「我们问客户 (产品负责人)一条问题，他/她用上两星期时间才回覆我们。我们找错了人吗？」不是，他们没找错人，他们是过程出问题——有些问题需要长时间研究，因为不 同部门和用户组要找出什么是正确，平衡各方需要的答案。分析员看著用例中一系列的伸延的形势可以找出那一个较容易，那一个较困难，再进一步进行相关的研 究。用户故事和 Backlog 项目未能及时达到适合作出来那考虑的粒度——伸延的形势通常要在Sprint中才能观察到，这已经太迟。

Alistair说了「为何不使用用户故事」后，进一步集中讨论「为什么使用用例」。

1. 目标名称列表将系统对业务和用户的贡献进行了最简短的概括，提供给行政人员。这也提供了一个项目计划框架，可用作建立初始优先次序、估计、团队分配，以及时间的选择。这也是“完整性”的第一部份。
2. 每个用例的主要成功场景能提供各参与者有关系统基本功能的协议，有时候更为重要的是，它可以告诉人们，哪些事情它不能做。给每一项需求提供脉络，这是其他工具很难办到的。
3. 每个用例的扩展条件可以给需求分析员提供一个框架，可以找出那些可能会用上 80% 的开发时间成本的烦琐细微之处。它提供一个考虑未来的机制，从而客户、产品负责人、业务分析员可以察觉到一些可能用上时间研究的问题。这些问题应优先处 理，让开发团队开始工作时这些资料也同时准备好。这用例伸延形势分析就是 "完整性" 的第二部份。
4. 用扩展场景提供一些仔细而然往往也是难处理的细节，像编程员常常问到：「你想我如何处理这情况？」（通常回覆却是：「我不知道, 我未想过会有这情况。」）换言之，这是一个思考、文档纪录的框架，跟“如果……那么……否则”的情况作配对，帮助编程员思考不同的问题。分别在於这是在研 究阶段进行，不是到要开始编程时才进行。
5. 整套用例系列反映出研究人员有详细思考不同用户需要，不同用户在 这系统上使用目的，以及一些业务上的差异。这是“完整性”的最后部份。（的确如是，我曾跟客户详细讨论长达 240 个用例，到最后，我去问她：「这是全部了吗？」她确认了。我们架建这系统，付运，收到应得的费用，而十年后这系统仍在使用。）

一如很多人所料，这回事不是黑白分明。我们该如何做好？我们现时在做的到底有用么？只有一个正确方法呢，还是有两个不同的 正确方法呢？或者视乎实际情况而定？会不会是有些情况下用用例较好，而有些情况下用用户故事较好呢？还是其实没太大分别呢——像用例中（或许）包含多个用 户故事而该用例因为一个用户情节内外都貌似用户故事呢）