Traditional Requirements vs. Agile Requirements

Projects are undertaken to realize customer’s requirements. These are elaborated upon in work items such as user stories, smart use cases, or features. These work items form the project’s backlog.

Just as in traditional projects, Agile requirements go through a number of stages in which different activities are carried out. In both types of projects, thought is given to the analysis, design, development, testing, and acceptance of the requirements. The greatest difference between traditional and Agile approaches is, therefore, not how the requirements are elaborated upon, but when they are elaborated upon.

We’ll compare the effectiveness of both approaches on the basis of a simple calculation.

Requirements in a traditional project

A traditional project starts with the elaboration of the requirements until they are complete and thorough. Complete means that all requirements are elaborated. Thorough means that all required details have been described. Traditionally, this is done to create a sense of security because the requirements are the basis for estimating the project’s expected costs and duration. This elaborated set of requirements results in the project plan.

In a traditional method such as this, a lot of time is devoted very early in the project to the elaboration of the requirements. Now suppose that, in a given project, there are 100 requirements, and each requires 20 hours for elaboration. In total, the team burns 2,000 hours to elaborate the requirements.

While many organizations assume that this is an efficient method that removes a great deal of uncertainty from the project, the opposite is true. There are still some contingencies that need to be taken into account.

• Knowledge: A lot of knowledge is needed to get the requirements to this high a degree of detail this early in the project. This knowledge is often not yet sufficiently developed this early on. Due to this, the elaboration of requirements takes much more time compared to the time it would take to elaborate the same requirements later on in the project.
• Clear: Many of the requirements aren’t yet clear this early in the project. The customer simply can’t decide about this much detail yet.

• Change: As everyone knows, requirements change during a project, regardless of whether the process is Waterfall or Agile. This is inescapable. There are new requirements and changing insights into existing requirements. Occasionally, requirements even become obsolete. Research shows that, on average, 20 to 25 percent of the requirements change. That’s at least four to five hundred hours in the example above.

  Elaborating requirements to such a high degree at an early stage in the project is therefore not effective. Moreover, why do we need this high degree of detail?

Requirements in an Agile project

Agile projects interact differently with requirements. Most of the work on requirements isn’t performed early in the project but only at the moment that the requirements are needed. This occurs at two moments.

• Estimation: At the start of the project, we’ll determine the size of the requirements so that an estimate can be issued. This, however, doesn’t require many details and it will be sufficient to identify the requirements.

• Realization: The details are only really needed when the requirements will be realized as work items during an iteration. Hence, the requirements and work items are further elaborated when they’re needed, just in time. This is a very different starting point for dealing with requirements. This principle is expressed in the acronym, YAGNI, which stands for, You aren’t gonna need it.” In short, this means that all of the work that’s currently not necessary shouldn’t be done now. Agile projects elaborate on the requirements only when it’s really necessary. For the requirements in the example project, early in the project, the requirements identified are worked out as far as is necessary to create an estimate. This requires much less detail than in a traditional project. Instead of spending 20 hours on one requirement, an Agile project perhaps needs four hours. Only when a requirement is selected as a work item is it then elaborated so that it contains enough detail for realization. This has remarkable advantages.

  • Progressive insight: Any new insights gleaned right up until the time of elaboration has been automatically incorporated. There are no change request forms to capture this progressive insight, and there isn’t any realization after the project has finished.
  • Knowledge: As a project progresses, both the customer and the team gain a lot of knowledge about the domain, the techniques used, and the technology. This knowledge ensures that the elaboration of the requirements later in the project takes less time. So, there’s less to investigate. This means that much less time is needed for a detailed elaboration of the requirements, perhaps maybe only eight hours per requirement.
  • Certainty: Finally, it’s certain that a requirement will be realized when it’s selected in the iteration. Here, Agile projects again save time compared to traditional projects. In traditional projects, requirements may be elaborated, but never realized, as the project changes. In Agile projects, requirements are only elaborated if they’re to be realized.

In conclusion, the same work is done to elaborate requirements in both traditional and Agile projects, but the moment when it happens varies enormously. In our calculation example, the Agile project saves eight hours per requirement.

This example is imaginary, but certainly not inconceivable. This way, progressive insight is working for me instead of against me.

Note: This example is imaginary, but certainly not inconceivable. This way, progressive insight is working for me instead of against me.