瀑布式开发通常会花几个月的时间来规划产品，然后再花几个月时间研发产品，接着进行产品测试、评审。最终发布产品。重点是，如果市场需求或技术环境发生变化，你此时研发出的产品很可能无法满足市场需求，瀑布式开发在遇到这种变化时会出现很多问题。
首先，产品规划必须早于后续工作之前完成，绝大部门案例中，规划环节结束时并没有完全理解项目，但研发工作已经完成了。通常情况下，整个项目必须送回规划阶段，然后从头再来，否则，研发人员就会因为不明白产品规划而受到批评，这种情况会反复出现，比如研发完成了，进行产品测试，发现问题就得重新开发，有时甚至要重新规划产品。在接下来的Review、Deploy等步骤中，也会多次出现同样的问题，这很可能导致产品发布时间跳票，短则几个月，长则数年。
当我们用Scrum来实施敏捷开发时就大不相同，整个项目会被分解成不同的小部分，首先，我们围绕最小化可行产品的特性进行产品规划，然后把最小可行华产品开发出来，接下来，我们测试和评审这个产品，直到准备发布。循环这个过程，我们就会得到一个可发布的产品，这个过程通常只需要一到三周左右，我们不断重复这个过程，以减少从产品规划到开发测试每个阶段的时间，我们去做详细的规划来完成下一个增量式发布，而你此时得到了几个增量式版本，称为Sprint（冲刺），一个Sprint通常需要一到三个星期，而你知识不断重复Sprint直到你的产品功能齐全。有时你可能会在第二次Sprint之后，或者第三次、第四次，甚至更久的时候，最终构成你的产品。但不管怎么说，最后你有了一个可发布版本。
在Scrum的方法体系中，有三个关键角色能帮助团队工作地更好，首先是产品经理，负责确定产品特性，同时产品经理会提出产品亮点，ScrumMaster是整个团队的负责人，负责帮助团队尽其可能完成工作，组织日常会议和保障其他工作，Scrum团队的成员由开发人员、测试人员、文案以及其他帮助研发的人组成，无论哪种方式，团队都在努力让产品完成，
在Scrum中有三种常用的可视化文档：第一种文档是，产品需求列表，产品经理会先从众多用户故事中筛选出优先项，并把他们列入产品开发列表中，需求列表会随着每次的Sprint迭代和更改。
用户故事，是一种表达产品需求的语言格式，格式为【作为一名 xx 用户，我需要
xx 功能，能够 xx 。】产品经理通过用户故事来了解需求的细节，为Scrum团队合理制定任务优先级，最优项的用户故事将进入Sprint代办列表，剩下的继续评估优先级，交到下次Sprint中。
燃尽图，用以展示整个Sprint代办列表的进度，当燃尽图曲线接近于0时，也就意味着这次Sprint即将完工。
Scrum方法中有3种不同形式的会议需要用到：Sprint计划会议，是产品经理、ScrumMaster和开发团队碰头的会议，用于讨论用户故事并估算任务量。每日例会，也就是我们所熟知的站会，整个团队会简述工作进度，并且讨论是否有任务需要搁置或是加派人手。Sprint临近尾声时，我们会进行Sprint回顾会议。这时研发团队会向产品经理演示开发好的功能，然后整个团队讨论是否有需要改进的地方。
我们一起回顾下Scrum工作流程，首先，产品经理把那些需要上线的产品特性做成产品需求列表（Backlog），然后由产品经理甄选出最优项，准备交给整个团队讨论。第二阶段，召开Sprint规划会议，研发团队、产品经理和ScrumMaster讨论用户故事优先项，并且决定下次Sprint要研发的需求项。第三阶段，根据Sprint规划会议制定Sprint需求列表。这个列表就是指经过团队讨论后的用户故事，用于下次的Sprint，会议结束后，整个研发团队和项目经理必须要对每个用户故事有深刻的理解。第四阶段，研发团队要在一到三周的时间里开发完成Sprint列表中的需求，在Sprint期间，每日站会用于团队交流他们做完了什么，正在做什么，以及遇到的问题。Sprint的产出是一个可以发布的产品版本，是否可发布由产品经理来决定，也可以在发布前增加新功能。第五阶段，在Sprint结束时会举行Sprint回顾会议。Sprint回顾阶段，由研发团队向产品经理做案例演示，同时团队一起反思工作中可以改进的地方。每次的Sprint结束后都要进行这种回顾。