Why We Capture Requirements Differently in Waterfall and Scrum

DZone 's Guide to

Why We Capture Requirements Differently in Waterfall and Scrum

The answer is, agility. The ability to quickly capture and reprioritize requirements allows Scrum teams to change their plan on a dime, if need be.

· Agile Zone ·
Free Resource

As a Principal Agile Consultant, I am frequently asked why the methods for capturing requirements are different in traditional Waterfall and Scrum.  Why do we try to capture full requirements up front in Waterfall, but we only try to stay four to five iterations ahead of current delivery in Scrum? 

A Waterfall business analyst asked me, "if you had your choice of having a high-level requirements matrix that covered 90% of the likely functionality as output out of iteration 0, or on the other hand, not having it at all, would you turn it down?" My question back was, “at what level are the requirements expected to be at? Were requirements defined at the Portfolio, Large Project, Program, or Team level?” If the requirements are at the Portfolio or Large Project level, this is a requirement so that you can strategically plan. Alternatively, if the intent was at the program or team level, most units of work are volatile and have the potential to change. Because of that, a lot of wasted effort is possible, and we don't want to work too far ahead. The intent is one reason why Scrum requirements (Stories) are done differently than Waterfall.

Many fans of Waterfall insist that you can't appropriately size the project or understand the architecture that is needed if you don't document every facet up front.  Based upon having exact requirements a project team should be able to accurately estimate the time to complete the schedule, the price, and the size of the team that is needed to complete the project. You will hear the Waterfall enthusiasts state that companies are becoming very impatient with cost overruns, and thus it is so important to understand all the requirements up front. I am a firm believer that most stakeholders do not necessarily know precisely what they want until they see it.  Unfortunately, with Waterfall, the stakeholder does not know what they are going to get until the user acceptance phase. Any changes that were not originally scoped are considered change requests, which costs more money and can drive a wedge between IT and the Stakeholder. 

With Scrum initiatives, only the high-level work is documented to give a very high-level effort, timeline, and cost. In Scrum, we sell value over selling an exact schedule, cost, and a fixed scope. It is in the first weeks of the project (Iteration 0), we document the first 4-6 iterations worth of work and try to stay that far ahead at all times. For a stakeholder that has never experienced this approach, this is a paradigm shift and can be a potentially scary proposition. Specifically, Scrum as an Agile framework, is a fixed cost, fixed time, but variable in scope. We are selling value above everything else. The project will always stay on target and within the original cost. It is the scope that is subject to change. In Scrum, the Stakeholder understands going into the engagement that if something new is needed, something else has to move down in priority and the potential may not be accomplished. The time and cost will remain the same, but the product owner decides the priority of the work completed and accepted. This method is entirely different than change requests under a Waterfall approach.

I had a student ask me this weekend during a Scaled Scrum Master course I was instructing, how to handle the warranty period of a product. Apparently, he was still struggling with the concept of Scrum. I told him that there is no warranty period in Scrum. We try to build quality into everything that we do through small increments, and many inspect and adapt rituals. If a defect does happen to make it into production, then a story requirement is created, and it goes in the product backlog with everything else. Once evaluated by the Product Owner and prioritized, it will make it in the appropriate iteration to be fixed. In some organizations, the defect work is allocated to a particular Break-Fix Kanban team so that it does not affect the velocity of the continuous application development teams.

Obviously, Waterfall projects have been around for years and are very entrenched in many PMOs, in many companies. It is a great framework for projects that are very similar in nature or unchanging. It does not, however, lend itself to the ability to change on a dime for companies that need to keep up with the competition. Both Scrum and Waterfall are still very alive and well and should be able to coexist for the foreseeable future.

agile adoption ,agile ,scrum ,waterfall ,software requirements

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}