用户故事得到这么多人的肯定，是因为它自身的优势有很多：1、用户故事强调口头沟通，因为传统的通过各种文档进行表达，每个人对于文字的含义的理解都不同，所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响；2、人人都可以理解用户故事，并且用户故事可以增强人们对各种事件的记忆；3、用户故事的大小适合做发布规划以及进行编程和测试；4、用户故事适合于迭代开发，项目过程中可以写出一部分故事然后就进行编码和测试5、用户故事鼓励延迟细节；6、用户故事支持随机应变的开发，因为用户故事注重口头交流，而且很容易写出或重写出不同粒度的细节；7、用户故事鼓励有参与性设计，因为故事简单易懂，能够激发用户的积极性使之成为软件设计的参与者；8、用户故事传播隐性知识。
任何事情都有两面性，所以用户故事也有其不足之处：1、在大型项目中，故事间的关系会很复杂，所以要尽量保证用户故事不要过于细节化，直到开发这些故事时才开始细化；2、如果开发过程规定要有需求的可追溯性，就需要有额外的文档，所以会花费一些额外的时间按激昂故事挪入或挪出来保持文档的更新；3、虽然故事能够促进团队内部隐性知识的基类，但是不适用于特大规模多团队的结构，然后就需要将某些交流的信息记录下来，以保证团队内信息的充分共享。
用户故事虽然较之其他需求方法更为简单，但也不是很好把握它的标准。所以使用用户故事时会有一些不良征兆：1、症状：经常需要调整估算，表现：故事太小；2、症状：很难做迭代计划，表现：故事相互依赖；3、症状：开发人员子啊迭代过程中实现了计划外的功能，或者仅仅凭借自己的感觉实现故事，或实现的功能超出了实际需要，表现：开发人员实现了不需要的功能；4、症状：花费太多时间去讨论细节；5、症状：过早考虑用户界面细节；6、症状：故事划分太过频繁；7、症状：很难为故事安排优先级；8、症状：可不不愿意写用户故事，也不愿意为故事安排优先级。
用户故事在应用过程中还会遇到一些问题：1、处理非功能性需求：非功能性需求往往无法恰当地以故事形式来表达。非功能性需求类型如下：性能、准确性、可移植性、可重用性、可维护性、互操作性、可用性、易用性、安全性、容量。大多数的非功能性需求是约束，所以非功能性需求可以以约束卡的形式出现在项目中。2、纸质还是软件? 纸质卡片和软件各有各的好处，纸质卡片较为方便带入各种会议，但是卡片的尺寸不利于写测试用例，但是可以给故事描述文本一个自然的上限，而且排序较简单。软件有利于不在同一个地点团队使用，而且客户更倾向于用软件而不是纸质卡片。所以在具体使用时要根据团队情况具体选择纸质或软件来记录故事。3、用户故事和用户界面：对于高度迭代的敏捷过程来说，传统的用户界面设计方法严重依赖于前期的设计，所以导致用户界面实现后期或许会有很大的改动。所以产生了就产生了适用于敏捷流程的设计：1、用户角色建模；2、捕捞高层次的用户故事；3、排列故事优先级；4、精炼高优先级和中等优先级的故事；5、对故事整理分组；6、建立书面的原型；7、精炼该原型；8、开始编程。3、是否保留故事：为了之后对产品的维护以及可重写性和项目结束后一些文档的需求，保留故事更为有价值。
总而言之，用户故事的优势使其在众多需求方法中脱颖而出，而其也有不足之处，这些不足之处需要一些额外的花费来弥补；用户故事虽然简单易懂，但是很好的使用它也不容易，所以要留意迭代过程中可能出现的各种症状，然后对症下药；还有就是用户故事可能会与传统的开发过程中的一些习惯有冲突，然后就需要人们根据其特性，适当做出改变。