Scrum vs. Waterfall

This is a post that I published on my (now defunct) personal blog a while ago. It’s a general comparison of some concepts in Scrum and their equivalent in a traditional project management workflow. I’ve intentionally avoided mentioning the advantages or disadvantages of either — you can make up your own mind about that.

The descriptions below are simplified and don’t take into account any specific waterfall methodology.

Requirements vs. User Stories

Waterfall – Defines requirements in detail. Every aspect of the project is defined and documented. Typically, a sign-off process follows, often in the form of a contractual agreement between the developer and the customer.

Scrum – Defines requirements as user stories. These don’t define technical requirements, instead they describe user goals and tasks. Each story is defined in full at the time it’s built. It’s unusual for a contractual agreement to be drawn up which allows the project to proceed. Instead, the team begins work on the most important user stories.

Predictive vs. Empirical

Waterfall – Defines requirements predictively. Take functional specs as an example. Traditionally, you’d define all requirements at the start of the project and have them approved by the client before any design or build work takes place.

Scrum – Defines requirements empirically. Instead of planning everything up-front, we define high level user stories. We then work on each of these in order of value to the project. A story is worked on intensively until it is 100% complete, from design to build to testing. Scrum accepts that a problem can’t always be fully understood at the start of a project.

Individuals vs. Teams

Waterfall — Individuals are responsible for the delivery of their part of the project. A hierarchical structure consists of project manager(s) who hold overall responsibility for delivery of the project. Individuals often work on multiple projects at the same time.

Scrum — A team is assigned to the project. The team consists of each individual required to deliver the project. This whole team is available and dedicated to the project until it is complete. No hierarchy exists and the entire team takes responsibility for delivery of the project.

Sequential vs. Iterative

Waterfall – Plans a project timeline as a sequence of stages. Each stage is dependent on the completion of the last. The entire project timeline is planned at the start. A releasable product is delivered at the end of the project timeline.

Scrum – The project timeline is made up of iterations (typically lasting 2-4 weeks). At the start of each iteration the team and client decide which features will be delivered. They commit to the delivery of those features within that iteration. An iteration results in the production of complete, releasable functionality that is designed, built and tested.

Cost of change vs. Encouraged change

Waterfall – Contractual agreements and sign-offs occur at each stage of the project. To go backwards and refactor previously completed stages, is often hindered by these agreements and may require increased budget and an extended timeline. Change can be costly.

Scrum – Change is welcomed at all stages of the project. A story completed and delivered during one iteration, may be changed and modified later on in the project if improvements can be made. To allow for these changes, stories yet to be delivered are often scaled down or removed entirely, avoiding the need to increase budget.

Wikipedia – Scrum (development)
Wikipedia – Waterfall