敏捷开发执行过程中的误解：
敏捷开发=开发效率提高
scrum不是一种技术框架，其目的是提高产品质量，让项目成功。在开发过程中，团队需要遵循scrum框架的各项事件活动，这些事件活动都是需要一定时间的，在一定程度上甚至会降低开发效率，但产品质量上会提升，这里的质量指的是，产品是否符合客户的需求，符合就有价值，不符合就没有价值。也就是说，scrum的力，发在团队上，效果体现在产品价值上。并不是说使用了scrum框架后，可以在单位时间内做更多的事。
敏捷开发=Scrum
敏捷开发有很多流派，如极限编程、DSDM、ASD、FDD等，Scrum只是其中的一个流派。
工时=故事点数 * x
工时是绝对估算，故事点数是相对估算。二者之间没有绝对的换算关系。在scrum中，使用的是故事点数进行度量。在考虑个人和团队产能的时候，应该是：故事点数/周期。
敏捷只能用在软件开发领域
敏捷最早起源于软件开发领域，所以其中很多术语都是和软件开发相关。但是其思想是超脱于软件开发的，可以适用于其他行业。现在已经有很多非软件开发企业开始使用敏捷了。
迭代开发=把功能分段开发
从大方向上来讲这是没错的，只是，分阶段也有横切和竖切之分。比如画一个人物画像，横切指的是：先画人体的大概轮廓，让头、四肢等有一个初步的形状，然后再细化各部分。竖切指的是：先画其中一部分，比如头，把头画的完美无缺了，再画其他一个个的部位。二者的区别是什么？修改的代价不同，画完头以后，发现位置需要调整，那么横切方式可以很快修改，竖切方式就需要费很多时间了。在这里画画不能与软件开发过程严格对应，主要强调的是思想：修改的代价有多大，或者是否还有修改的机会，问题越早暴露越易修改。在软件开发中，Scrum强调持续的将阶段性产品演示给客户，及早获取客户反馈，及早修改。
有敏捷开发了就不需要瀑布模型了
瀑布模型有其重大缺点，但并非全是缺点。我们推崇敏捷开发，但不是完全否定瀑布模型。
客户知道自己想要什么
通常大部分客户都是知道自己的需求意向是什么，但具体的表达形式，是不确定的。一个需求功能，有很多方式去实现，我们需要找到最符合客户心意的那个表达方式，而scrum框架就是管理这个过程的，通过持续频密的与客户沟通反复验证，直至客户满意。
拒绝需求变更
客户在某一时间点做出的需求，并不都是百分百完美正确的，很大程度上客户的需求也在持续改进提高。变化改进产生更高的价值，scrum拥抱需求变更，哪怕是在项目后期。我们不应机械的完成客户需求，而是应与客户合作共同提高。
scrum只适用于小团队
scrum的最佳实践，在于3-9人的小团队。但企业也可以采用LeSS，这是scrum中针对规模化的敏捷框架。
