用户故事具有多种好处：
①用户故事强调口头沟通：自古以来，口头表达是十分重要的。而且相比于书面书写的易产生歧义，口头表述更见简单明了，需求文档也是如此。
②人人都可以理解用户故事：相比于一些墨守成规的软件需求里的技术术语，用户故事使用的语言更容易使用户理解，简洁明了，同时更能增强用户对故事的记忆。
③用户故事的大小适合做计划：其他类型的需求分析关联性太强，并且还比较笼统，大小不能称得上是易实现的适合需求。
④用户故事适合于迭代开发：由于用户故事的特性，使得开发者可以根据当前需要，按照想要的进度实施开发。
⑤用户故事鼓励延迟细节：用户故事允许我们先设定一个目标层面的故事，之后实际开发的时候，再将其细节化，加快整个团队的进度。
⑥用户故事支持随机应变的开发：由于用户的不可控性，需求常常会变动。在以往从上到下的需求分析方法中，这简直就是噩梦，它会让我们前期定下的所有需求全部作废。用户故事则很好的解决了这一点。
⑦用户故事鼓励参与性设计：用户故事本身不像其他需求方法都是专业术语，用户可以完全理解，他们也就更愿意参与设计他们所需要的软件。在这个过程中，我们就能更好的了解用户的需求，做出更优质的分析。
⑧用户故事传播隐性知识：隐性知识指的是目标系统的既有属性，用户在工作时习以为常，认为我们应该知道，但是我们因为不熟悉流程无从知晓的知识。由于用户可以参与设计，这就有利于我们挖掘出用户的潜在需求，缩短我们的开发周期。
尽管如此，用户故事仍但会存在一些不足：在大型项目中，用户故事数量增长，导致其间的关系可能错综复杂，不易掌控（解决方案：增加用户，降低细节数量）；开发过程如果需要可追溯性，额外文档还是不可避免（每轮迭代产生故事文档，其中写入该轮迭代的工作，保持文档的更新）；不适合特大规模多团队的结构（还是需要进行相关的交流记录）。
用户故事虽好，但是使用起来也不简单，如果使用不善，还是会出现各式各样的问题。下面就是一些常见的不良征兆（症状，解决方案）：故事太小（经常需要调整估算，将相关的故事进行合并）、故事相互依赖（很难做迭代计划，如果因为故事小就相应合并或者是看一看故事划分是否得当）、镀金（实现功能超出计划需要、开发者因此浪费额外精力，规定好每次迭代计划的每人工作尽量减少冗余）、细节太多（浪费过多时间写故事而非讨论收集故事，使用小卡片记录用户故事）、过早考虑用户界面细节（编写的故事中包括界面细节，避免或者修改成具体的功能描述）、想的太远（由于种种原因导致故事难以整理总结，让开发者学会收集用户故事）、故事划分太过频繁（多次划分，扫描剩余故事找到真正需要划分的故事）、客户很难为故事安排优先级（故事太大或者用户故事无商业价值，更换小故事、让客户努力重写）、客户不愿意写故事，也不愿意为故事安排优先级（不愿承担相应责任，和用户私下讨论交涉）。解决这些问题，用户故事才能更健壮，开发也就更加流畅。