Every software project carries some risk, but many of these risks can be mitigated. That's true of problems related to product requirements—problems that are often cited as one of highest risks for any type of software project. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry.
Project teams can make a difference by adopting and implementing agile practices. When implemented correctly, agile practices greatly mitigate the most common risks associated with requirements on software development projects. Adapting the requirements risks I discuss in my book The Software Requirements Memory Jogger , I will explain how agile practices act to mitigate the risks—and, therefore, provide the business value for which these practices aim.
Risk 1: Unrealistic Customer Expectations and Developer Gold-Plating
This is the risk that your customer's wishes will exceed what your team can deliver or that developers—in their sincere quest to satisfy their customers—will add unnecessary features.
How does agile address these problems? In agile projects, we chop up delivery expectations into short iterations—one- to three-week timeboxes. Each timebox begins with an iteration planning workshop in which the customer decides which work should be delivered.
The process is entirely transparent:
- The customer states the goal or theme for the iteration.
- The delivery team members state how much time they have to devote to the effort (i.e., their capacity, usually in work hours).
- The customer selects the highest-priority requirements from the backlog (the master catalog of work needed to build the product).
- The desired requirements are further discussed and elaborated on, as needed.
- The team estimates and tasks out the work.
- The team and the customer explore risks and dependences.
- The team makes an explicit commitment about which requirements will be delivered.
As an analyst and coach, I find that the key to this process is having each work item (also called a story) small and sharply defined. If you don't know the completion criteria up front—to assess whether a requirement is "done"—then the customer's expectations might be dashed or delivery team members might make (wrong) assumptions and add extras.
Throughout the iteration, the team checks on expectations by showing completed stories to the customer. At the completion of each iteration, team members show any stakeholders all the completed work in a demonstration and review.
Risk 2: Insufficient Customer Involvement
The most commonly cited project risk is a lack of engagement by customers. A precondition on agile projects is that we require the customer to participate throughout each iteration. As just described, the customer declares the iteration goal and work at the start, reviews completed work during the iteration, and attends the demo or review at the close of every iteration. In addition, the customer must always be available to answer questions about requirements.
When customers are less available, then domain-knowledgeable business analysts act as proxy customers to help with requirements analysis. Thus, business analysts become customers; they are delegated the decision-making authority about requirements priorities. In other cases, I have seen business analysts act as coaches and aides to customers, helping them define concise and clear requirements, prune the ever-changing product backlog, analyze backlog items to prepare the team for the iteration planning workshop, and document requirements.
No matter who assumes the customer role, it is front and center on an agile project.
Senior-level customer involvement is also crucial, particularly on large, complex projects. These executives set the context for the product development effort by participating in product roadmapping to define the product vision and lay out which features will be delivered over time based on market and technology needs and constraints.