A Sprint is Not a Mini Waterfall

When someone tells me, "A Sprint is mini Waterfall," I quickly respond, "No!" And I do this often, because time and again I hear this opinion from people who are new to Agile. I even hear it from teams who have been executing projects using Agile software development methodology. In this article, let's examine five reasons why a Sprint is not a mini Waterfall

1. Continuous design, development, integration, and testing 2. Cross-functional team members 3. No change in scope during Sprint 4. Time boxing 5. A strictly defined cadence

1. Continuous design, development, integration, and testing

The design, development, integration, and testing (DDIT) stage within a Sprint is a continuous activity, not the sequential process it is in a Waterfall project. The graphics below illustrate this difference:

Waterfall Project

Agile Project

2. Cross-functional team members

A Sprint group is one cross-functional team working in a dynamic, often fluid manner. It is not a set of different teams working separately and handing off work from one to another, as is the case with Waterfall projects:

Waterfall Project Team

Agile Project Team

3. No change in scope during Sprint

Waterfall projects define a rigid scope-change control process to manage any changes to work already underway. In contrast, Agile scope-change control, by design, is virtually nonexistent. This gives the product owner the flexibility to change his or her mind between Sprints. However, once the Sprint begins, the scope is frozen and no change request is allowed until that Sprint is complete.

Waterfall Project

Agile Project

4. Time Boxing

A Sprint is always time-boxed, no matter how the Sprint progresses. In the Waterfall world, if the project is behind schedule, the project timelines are usually extended. In the Agile world, the Sprint duration does not change–it is time-boxed–even if all the committed scope could not be completed during the duration of the Sprint. If, at the end of planned Sprint duration, there are scope items that are not complete, they are put back into the product backlog, prioritized, and made ready for future Sprints.

5. A strictly defined cadence

In a Waterfall project, the cadence cannot be defined up front. A Sprint, in contrast, always works on a well-defined cadence. The graphic below depicts a typical two-week Sprint cadence:

Sprint Cadence

These five characteristics of Sprint versus Waterfall project methodologies clarify major differences between the two. Don't let yourself—or your team—make the mistake of thinking that Sprint methodology is "just" a mini Waterfall.