Scrum Versus Waterfall for Product Development

In this post – Agile Scrum versus Waterfall, I compare managing a software development project with the traditional waterfall approach and to managing the same software development using the agile/scrum framework.

Waterfall Project Management

In a traditional waterfall project the project phases cascade, like a waterfall, the phases are done in series, maybe with a little overlap if the project manager feels the risk is acceptable

Once a phase has been completed it’s very difficult and costly to go back and make changes.

There’s no room for error so the initial specifications and requirements need to be comprehensive and frozen.

That’s how software was developed years ago because at that time it was the only way to do projects

Waterfall Process

Plan frozen on day 1 –

  • Requirements
  • Specifications
  • Schedule
  • Budget
  • Everything

And the customer knew what to expect because he defined the requirements and the specifications and agreed the time schedule and the cost before the project work started.

Well over time this traditional approach was seen to be too restrictive, very cumbersome to control the inevitable changes required by the end users and the whole deliverable was not tested until the product was ready for release.

So if any code was not written correctly it would not be found until probably too late and correcting the code was for sure very expensive

Not good in these fast moving times, right?

Agile Scrum Product Development

Then along comes a different way of working, more flexible, more Agile.

Agile Scrum Framework

  • Small scope in short time frames
  • Tested, demonstrated, accepted
  • Bugs discovered quickly
  • Customer feedback included

And the scrum framework was developed and has become the most popular agile framework for software development.

Agile Scrum Process

Developers start off with a simple project design and then begin to work on small modules.

The work on these modules is done in short time periods and at the end of each time period, or sprint, the work is tested, project priorities are evaluated for the next lump of work.

These sprints allow bugs to be discovered and customer feedback to be incorporated into the design before the next sprint is run.

And this same framework can also used to develop many other products, not just software applications.

In the agile scrum way of doing things –

The initial planning is done: Developing the product backlog, release planning and the first sprint backlog

Remember, The sprint backlog is a list of features and functions that can be developed within the fixed time box of the sprint

The development team take the sprint backlog

  • Analyse
  • Develop
  • Test
  • Integrate
  • Validate
  • And deliver that work in the sprint review

More planning at the product level is done: This is the product backlog grooming sessions

More planning at the sprint or iteration level is done: This is the sprint planning meeting

The work in the next sprint is done. And delivered

The sprint includes a little product backlog grooming, a lot of sprint planning

And then the work of the sprint

At the end of each sprint an increment of the final product is delivered. A potentially shippable product

And the short bursts of product development continue until the final release

Scrum Versus Waterfall

So there you have it a quick comparison between waterfall project management and agile scum product development


  • Allows for changes to be made to the requirements as the product is being developed
  • Testing at the end of each sprint allows for quick and cost effective bug fixes
  • A potentially shippable product is produced at the end of each sprint

Find More

Related Content