Waterfall, Agile and the Backlog
Ah, the dreaded backlog. Take a look at how Waterfall and Agile both approach project backlog, and see which one handles it better.
Join the DZone community and get the full member experience.Join For Free
One of the biggest differences in software development between a phased waterfall approach and Agile Scrum is the fundamental assumptions about the backlog. Regardless of the methodology, all projects have a list of features, bugs and technical issues that require work. It is the backlog. Executing on this list of items is the work at hand. It is the project.
We know that the total analysis effort with waterfall is spent up front by reviewing requirements and supporting artifacts supplied by the stakeholders and other SMEs. The backlog requirements are consumed in total up front with the assumption that the features contained in the backlog are sufficient to guide us to project completion with a state of delighted users.
Unfortunately, there is a fallacy with this assumption that has plagued projects for a long time. For most projects, where user requirements make up a large portion of the backlog, the backlog as defined in the beginning of the project cannot guide you to project completion with delighted users. This is because the backlog was created by people who are not “all knowing” and who are computing in an environment that often in a state of change. The backlog at project initiation is embedded with three basic problems:
- It is incomplete. Important high priority items will arise that people didn’t anticipate or think about.
- It is static. Technology will change, and the supporting environment may drift during the project.
- It contains errors. At the beginning of a project, users have trouble describing what they need and want. And analysts have trouble interpreting and documenting what the user is describing.
In short, the backlog at project initiation is sick and waterfall assumes it to be healthy. Over time, this misconception has caused project managers and software house leaders to take a defensive approach – thus phase gate signatures, scope lock, and scope change documents were born.
The good news is that there is a better way to work. Agile Scrum recognizes this falsehood and embraces it. It knows the backlog is unhealthy. Agile Scrum sees the backlog as infinitely dynamic and expects it to remediate in health over the life of the project. In fact, we all depend on it.
Once we begin demonstrating increments to the users and stakeholders, they become enlightened and their perspective reforms. Every time we incorporate feedback from the sprint review into the backlog with new or updated stories, we enhance the health of the backlog. Every time we listen to the users (inspect) and adapt to their insights, we improve the backlog. Every time we recalibrate our direction using an improving backlog, we move closer to delighted users.
Opinions expressed by DZone contributors are their own.