Agile development approaches are currently used in most software organizations at least some of the time. With the rise in popularity of agile methods, business analysts and product owners often use the term “agile requirements” to label their work.

We do not care for the term “agile requirements” because it implies that the requirements for an agile project are somehow qualitatively different from those for projects following other life cycles. A developer needs to know the same information to be able to correctly implement the right functionality regardless of the life cycle being used.

Agile and traditional projects do handle requirements differently in various respects, particularly with regard to the timing and depth of requirements activities and the extent of written requirements documentation. Nonetheless, most established techniques for requirements development and management are useful on agile projects when thoughtfully applied, as described in our book, Software Requirements, 3rd Edition (Microsoft Press, 2013). This is why we prefer the term “requirements for agile projects” over “agile requirements.”

Traditional approaches, such as waterfall development, attempt to minimize project risk by doing extensive specification and planning prior to initiating construction of the software. In this way the project managers and BAs make sure that all stakeholders understand exactly what will be delivered before it gets built. This can work well if the requirements are well understood at the outset and are likely to remain relatively stable during the project.

Agile approaches are designed to accommodate and adapt to the inevitable change that takes place on many projects. They also work well for projects with highly uncertain or volatile requirements. However, agile projects require, fundamentally, the same types of requirements activities as traditional development projects. Someone still needs to identify user classes and other stakeholders, elicit requirements from appropriate user representatives, analyze and document requirements of various kinds at appropriate levels of detail, and validate that the requirements will achieve the project’s business objectives.

However, detailed requirements are not documented all at once, at the beginning of an agile project. Instead, high-level requirements, typically in the form of user stories, are elicited to populate a product backlog early in a project for planning and prioritization.

There Is a Difference

The major differences between how requirements activities are handled on agile and traditional projects fall into the following categories:

• Roles and Responsibilities – the job title of who does the “requirements” or analysis work is different.
• Timing of Requirements Activities – similar activities are performed in smaller chunks ongoing throughout the project.
• Deliverable Forms – the outputs of requirements activities have different names and take different forms.
• Terminology – activities and artifacts have different names, such as user stories and acceptance criteria instead of requirements.
• Documentation Detail – less detail might be captured in formality.
• When to Prioritize – instead of prioritizing up front, items are frequently being prioritized throughout the project.

We have lots more to say on these points. If you want to read more, grab our full article as it’s too long for blog format! The article continues the discussion with a lot more detail on the 6 categories of differences in agile approaches.

Joy co-authored this article with Karl Wiegers, Principal Consultant at Process Impact, www.processimpact.com. Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.