Agile Requirements: What’s the Big Deal?


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

Agile projects often do not assign a dedicated business analyst to perform elicitation, analysis, specification, and reviews. Developing requirements-related information is a collaborative process among people performing the role of analyst, regardless of their actual job titles, and suitable user representatives and other stakeholders. The analyst role commonly is performed by a combination of a product owner, developers, and key business stakeholders.

On an agile project, a product owner typically is responsible for the product backlog and for getting the user stories ready to be implemented. The developers are responsible for ensuring the user stories contain enough information before accepting them for development. Sometimes the product owner role is filled by someone who was formerly known as a business analyst, as long as that individual knows the business well and can represent the various user communities effectively. Other projects do have a dedicated BA who works closely with the product owner to ensure user stories are sufficiently elaborated and prioritized for development.

Timing of Requirements Activities

In any software development approach, starting with a broad exploration of requirements at a high level of abstraction allows you to do some initial prioritization, estimation, and sequencing. Traditional approaches emphasize creating a fairly complete and detailed requirements specification early in the project. In contrast, agile teams plan to generate the requirements details just prior to implementing a specific set of functionality. This reduces the risk of the information being obsolete when developers and testers need to act on it, and it helps the team to refine priorities. However, a just-in-time approach makes it harder to recognize requirement dependencies and architectural implications that should be addressed from the very beginning. To mitigate the risk of a flawed architecture, agile teams often do look at the broad scope in early iterations and consider what major architectural decisions might be necessary.

As shown in Figure 1, agile user stories are allocated to specific iterations for implementation, and the details for each story are further clarified just in time for, or during, that iteration. Functional requirements might continue to be developed in small portions throughout the entire project, even up until shortly before the product is released. As with architecture, though, it’s important to explore nonfunctional requirements early on so the system can be designed to achieve critical performance, usability, availability, and other quality goals. Addressing these factors late in the project can require extensive and expensive rework. Just as with traditional approaches, agile methods are about reducing the risk sufficiently to move forward. The big difference is that agile projects anticipate doing a certain amount of refactoring and rework, so teams are willing to accept more requirements uncertainty early on.

Standard requirements activities occur within each agile iteration

Figure 1.Standard requirements activities occur within each agile iteration.


Deliverable Forms

At the top level, user stories are comparable to the use cases often used on traditional projects. Again, the distinction is in how thoroughly you detail them and whether you record what you learned when you did. User stories often correspond to individual flows within a use case. The BA on a traditional project might work from use cases to develop a richer set of functional requirements. On an agile project, in contrast, the team commonly fleshes out the specifics of a user story by writing acceptance tests that will indicate whether the story has been properly implemented.

Karl has advocated developing tests in conjunction with requirements for nearly 25 years—long before the Agile Manifesto was born! But in reality, functional requirements and their corresponding granular tests are both ways to represent the same information, one describing what to build and the other specifying how to tell whether you’ve correctly built the right thing. A big advantage of thinking in terms of tests is that they are more likely to reveal exceptions that are often overlooked when specifying requirements. However, the disadvantage of using only one or the other is that it leaves you with but a single representation of the requirements knowledge. If you have only one view of the requirements, you must trust it to be correct.

We have found that writing both requirements and tests provides a powerful combination, particularly if a different person than the one who wrote the requirements writes the tests from the same source of information. Comparing those two alternative views is a great way to find gaps, ambiguities, and differences of interpretation. On agile projects this is not usually practical based on team roles, because product owners typically write both the user stories and the acceptance criteria.


The different forms used to represent requirements lead to an interesting but not terribly meaningful difference in the terminology used on traditional and agile projects. Most agile projects refer to user stories and acceptance criteria, whereas use cases and functional requirements are more commonly employed on traditional projects. But it’s really the same knowledge! It doesn’t matter much what you call it or exactly how you represent it, just so long as you produce and communicate that knowledge in a way that lets developers and testers do their jobs effectively and efficiently.

Documentation Detail

People sometimes think agile project teams aren’t supposed to write requirements. That is not accurate. Instead, agile methods embrace the principle of lightweight documentation. The close collaboration of customers with developers on agile projects generally means that requirements can be documented in less detail than on traditional projects. Instead, BAs or other people responsible for requirements will develop the necessary precision through conversations and documentation when it is needed. Any documentation beyond what the development and test teams need (or that is required to satisfy regulations or standards) potentially represents wasted effort unless there’s a definite need for it down the road. Certain user stories might have little detail provided, with only the riskiest or highest-impact functionality being elaborated in more detail, typically in the form of acceptance criteria and appropriate visual analysis models.

We believe the cost of recording information is small compared to the cost of acquiring that information. There is considerable merit in creating a persistent group memory in written form because human memories are incomplete, are inconsistent, and decay with time. People come and go on project teams, and of course the product continues to exist long after the development project is done. Each project needs to select a sensible balance point of just-enough documentation to manage those risks without spending unnecessary time recording information that won’t be used.

When to Prioritize

Prioritization of the backlog is an ongoing agile project activity to select which work items go into upcoming iterations and which items are discarded from the backlog. The priorities assigned to backlog items don’t have to remain constant forever, just for the period each is under development. The teams are always asking themselves: “What is the most important thing to work on next?” In contrast, most traditional projects try to prioritize requirements early and rarely look back. But really, all projects—not just agile projects—ought to dynamically manage the priorities of the work remaining in their backlog as it ebbs and flows.

Is There Really a Difference?

We recently saw a list of “Principles of Business Analysis” from the IIBA® Agile Extension to the BABOK® Guide that itemizes numerous practices in several categories. We are hard-pressed to see anything there that would not potentially be useful on any software project. Shouldn’t every team apply techniques to see the whole, think as a customer, stimulate collaboration, and avoid waste? All projects should define what business value means, ensure that both project activities and business process steps add value, and use practical prioritization methods. Techniques like personas, backlog management, relative estimation, and retrospectives are valuable practices that would benefit nearly any project. So what makes these BA principles and practices specific to agile projects?

Now, you could argue that traditional projects often do not conform to these principles or perhaps effectively apply any set of thoughtfully selected BA practices. Probably true. Probably just as true on agile projects that might not have organic BA expertise. But the basic point is that, the same requirements values, principles, and practices are equally applicable to any software project when thoughtfully adapted, scaled, and timed so as to enable the project to achieve its objectives. That’s why we just don’t get the idea that “agile requirements” are somehow different and special.

Authors:  Joy Beatty and Karl Wiegers

Joy Beatty is a Vice President at Seilevel, Karl Wiegers is Principal Consultant at Process Impact, Karl and Joy are co-authors of the recent book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Like this article:
  177 members liked this article


Ryan Milligan posted on Wednesday, July 6, 2016 1:24 PM
"It doesn’t matter much what you call it or exactly how you represent it, just so long as you produce and communicate that knowledge in a way that lets developers and testers do their jobs effectively and efficiently." Thank you, thank you, THANK YOU. With the evolution and momentum of Agile, too many people are getting caught up in what constitutes a user story versus a traditional requirement, and when each one should be used, as if the two are mutually exclusive concepts. I've written traditional requirements for Agile sprints, and I've written user stories for waterfall projects with smaller scope. Heck, I've derived documents that wouldn't fall under either bucket by definition but the developers ran with them and delivered things ahead of schedule. Some things aren't one-size-fits-all, but nothing is set in stone either. In the end, the business goals don't change based on the approach, and thus neither should the information conveyed in whatever is provided to enable implementation.
Karl Wiegers posted on Wednesday, July 6, 2016 3:14 PM
Nicely put, Ryan. I couldn't agree more. I'm not a purist when it comes to process, I'm a pragmatist. How about if BAs work with their developers and testers to agree on what forms of requirements information and what level of detail will best meet their needs, instead of either guessing or force-fitting things into any particular shape of box? It's called collaboration: I highly recommend it.
Gary K Evans posted on Thursday, July 14, 2016 12:21 PM
Well done, Joy and Karl. I totally agree that "agile requirements" is suggestive of a distinction without a difference. As I read your article I had ideas for a reply that would be as long as your article! So, I will focus on two topics.

In my experience as an Agilist, the hard part for traditional BAs or teams is the time metaphor for all delivery activities whether requirements, design, or coding. In Waterfall we do as much as we can, as early as we can, thinking this reduces risk. It does not. Risk is much higher in the later parts of a WF effort because of latent mistakes and unrecognized omissions. In Waterfall we specify requirements up-front to hit a moment in time; in Agile we specify requirements continually, over time. But in both approaches we can never claim our requirements are complete until we ship the product. Psychology, and corporate fear or tolerance for incompleteness, drive teams in one direction or the other.

I am 100% pleased that you have injected use cases into this discussion. Too many Agile people start with user stories and never mature beyond those. Stories are important as placeholders for discussion (Jeffries' Card-Conversation-Confirmation). However, stories have two specific criteria separate from their written form. One, they must be small enough to be estimated (as well as other INVEST criteria). Two, they must be small enough to be completed within a single sprint. Both of these are beneficial properties. However, these properties introduce risk of not understanding the context of the story. This is exactly why I bring use cases into my projects. Use cases provide the larger flow within which stories are realized. (The relationships between use cases and stories are complex and not limited to "a story is part of a use case.") I am continually amused when I ask a team, "Where does this story occur in the business process?" and I get several different answers.

I really like what you have written here. It is concise and gets across several very important concepts we all need to keep in mind. The bottom line is indeed: requirements are a property of the product, not the development approach. How and when we identify, and dive deep into, a requirement does differ, but the requirement is a required goal of the product regardless.
Steve Rose posted on Thursday, July 14, 2016 8:19 PM
One addendum: once you remove the assumption that requirements are static throughout the project, you add a new responsibility - checking that previously completed requirements are still valid: newly discovered information may require updating requirements (and then everything downstream). Technically this is categorised as 'rework', which is usually seen as bad, but in reality it is part of the price you pay for being 'agile'.
Lee Cash posted on Wednesday, August 24, 2016 4:48 PM
Agile is a "mindset" founded on frequent, periodic delivery of working software to customer in order to support incremental, iterative improvements.

There are many inter-related agile methodologies. However, using a methodology does not make a given project agile. As the authors clearly and correctly note, there are no "agile requirements," only "requirements for an agile project." Additionally, agile is indeed the opposite of micromanagement.
Gildas posted on Friday, September 2, 2016 11:48 AM
As long a user story will not include post and preconditions, trigger condition, minimum garantee, exception scenarios, we take the risk of under specification. The big deal is : how much RE the system requires ?
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC