How Agile Practices Reduce Requirements Risks

Risk 3: Poor Impact Analysis
It is rare to encounter products with fixed, clear requirements up front. Changes to requirements and shifting priorities can affect the sequence of work, introduce unforeseen rework, or create product defects.

Poor impact analysis involves not understanding the ways that new and evolving requirements affect the set of proposed requirements that make up the baseline (the traditional requirements term) or backlog (the agile term).

On agile projects, it's OK to change the backlog. Indeed, some teams agree that any team member can revise the backlog at any time. Other teams allow only the customer or the business analyst to modify the backlog. Whichever arrangement the team agrees to, the point is that team members recognize that the backlog of work is dynamic.

The product backlog is continually analyzed and adjusted. The customer, often with an analyst and perhaps other team members, prunes the backlog. When pruning, impact analysis is key: Items are broken down, analyzed for their interdependences, shifted up or down in priority, re-estimated, removed, and reallocated to iterations or releases. This happens weekly on most agile teams. Analyzing the impact of changing requirements is part of the rhythm of successful agile teams.

Risk 4: Scope Creep
The uncontrolled expansion of requirements throughout the project is the highest risk of any software project [2]. In addition, the larger the product, the more requirements grow. Yet, scope creep might actually be considered "normal."

Most software products present a wicked dilemma: The problem you are trying to solve is not fully understood until after it has been solved (i.e., some of the solution space lies within the problem space) [3]. If you cannot know what the solution is until you start to build the product, you benefit by starting to build it in small increments and then obtaining feedback to learn and adapt. This is the essence of agile development.

Some stability is, of course, necessary. Product goals, objectives, target market and users, and a product vision need to be articulated (agile teams do this as part of product and release planning).

It's OK to add new items or stories to the backlog as they arise. Agile teams manage scope creep by continually pruning the backlog.

The project's scope is defined at a high level but is not a binding contract. By working in short delivery cycles on a small subset of requirements, agile teams can better control scope. Every one to three months, they conduct release planning to adapt the requirements delivery plan over a longer time frame.

Risk 5: Defective Requirements
Requirements defects include missing, erroneous, conflicting, or ambiguous requirements, which can lead to a defective product. Even worse, it can lead to building the wrong product. On an agile project, small, concise requirements (stories) are sharply defined once the customer has chosen them from the backlog. Defining story "doneness" is essential. As mentioned earlier, the customer participates in iteration planning and is available throughout each iteration to answer requirements-related questions.

That leaves no wait time during which developers or testers make (wrong) assumptions about requirements. In addition, I like to have the team develop user acceptance tests as soon as work begins on each item. This form of validation is the best way to remove ambiguity from requirements.

A requirements defect also leads to excessive rework—revised code, additional testing, modified documentation, and premature or unnecessary analysis. On agile projects, we do not analyze backlog items until they move to the top of the backlog stack—when they are about to be pulled into an iteration planning workshop. This practice not only prevents us from analyzing requirements that will never be implemented but it also avoids rework caused by analyzing requirements prematurely. Additionally, many requirements are interdependent. When you analyze, build, test, and deliver a requirement, you learn things that will impact your understanding of related requirements. By waiting until the "last responsible moment" to conduct analysis, you are better informed and can tackle your analysis more efficiently.