Agile Requirements Lifecycle

ABOUT THIS CHAPTER   For the first 25 years I worked in software development, every study I saw that examined causes of project challenge and failure found that the leading cause of problems was poor requirements—requirements that were incomplete, incorrect, contradictory, and so on. For the past 10 years, the most common cause of challenges my company has found on Agile projects has been difficulty in filling the Product Owner role, which is really about—you guessed it—requirements.

Because requirements have been such a widespread and persistent source of software project challenges, I’m going to use the next two chapters to dive deeper into requirements specifics than I have into other topics.

Compared to 25 years ago, today we have some very effective requirements practices that can be used on Agile projects. These practices help with each of the main requirements development activities:

• Elicitation—initial discovery of requirements.

• Analysis—development of a richer and more refined understanding of requirements, including priorities among them.

• Specification—expression of the requirements in a persistent form.

• Validation—assurance that the requirements are the correct requirements (will satisfy customer needs) and that they are captured correctly.

For most of the techniques, there isn’t much difference in how a team would use them for an Agile or a Sequential project. What is different is when the team performs the activities.

This chapter describes the elicitation and specification activities and begins the discussion of analysis. The next chapter focuses on the prioritization aspect of analysis. The main techniques for validation of requirements on Agile projects include ongoing conversations about the requirements and the end-of-sprint review (that is, demonstrating the working software).

What’s different about Agile requirements?

Requirements work occurs at different times on Agile projects than it does on Sequential projects, as illustrated here: