Agile Requirements: Not an Oxymoron


Adult children. Jumbo shrimp. Seriously funny. I’m sure you recognize these expressions as oxymorons—self-contradictory phrases, often with an ironic meaning.

Should we add “agile requirements” to the list? Does agile development fit in with traditional requirements practices? And if so, how?

Once More into the Breach

Traditionally, defining requirements involves careful analysis and documentation and checking and rechecking for understanding. It’s a disciplined approach backed by documentation, including models and specifications. For many organizations, this means weeks or months of analysis, minimal cross-team collaboration, and reams of documentation.

In contrast, agile practices—Lean, Scrum, XP, FDD, Crystal, and so on—involve understanding small slices of requirements and developing them with an eye toward using tests as truth. You confirm customers’ needs by showing them delivered snippets of software.

But agile projects still produce requirements and documentation, and they involve plenty of analysis. On the best agile projects, requirements practices combine discipline, rigor, and analysis with speed, adaptation, and collaboration. Because software development is a knotty “wicked problem” with evolving requirements, using iterative and agile practices is not only common sense but also economically desirable.

Indeed, agile requirements drive identifying and delivering value during agile planning, development, and delivery.


Agile teams base product requirements on their business value—for example, boosting revenue, cutting costs, improving services, complying with regulatory constraints, and meeting market goals. If you’re agile, it means that you focus on value and jettison anything in the product or process that’s not valuable.

Planning covers not only the “now-view” (the current iteration) but also the “pre-view” (the release) and the “big-view” (the vision and product roadmap), with close attention to nonfunctional as well as functional requirements. The product roadmap is crucial for keeping your eyes on the prize, especially in large, complex products. You don’t have to know each specific route, but the overall way must be clear. It’s driven by the product vision and marked by industry events, dates, or key features that must be achieved along the route.

Customers (or “product owners,” in scrum terminology) drive agile planning, constantly reprioritizing requirements and evaluating risks and dependencies. Close customer collaboration is essential. One of the original agile methods, DSDM, has customer involvement as the first principle.

Your agile backlog, or catalog, of product needs changes constantly—whenever you do planning (e.g., for a release or iteration) or, if you’re using a kanban/flow model, every time you’re ready to pull in another requirement. Plans are based on deciding what to build, and when.

An agile delivery team works ahead, preparing requirements for development and testing. This preparation is vital to deliver the value as soon as possible, with smooth flow and no thrashing or interruptions in delivery and testing.


An agile team’s work is based on building concise, fine-grained requirements (typically captured as user stories). Developers need small, tamped-down requirements to work from. Small requirements that have clear conditions of satisfaction (doneness) minimize risk.

The team may also sketch organic data models, state diagrams, and interface mockups. These are like micro-specifications: “ready” requirements for pulling into delivery. The team knows enough to estimate, develop, test, and demonstrate the requirements.

Doneness is a key aspect of requirements. I wrote about “done” requirements in my first book (2002): the team and customer need to know when they understand the requirements enough to build and test. This concept is used often in agile development and refers not only to requirements but also to the build, test, and release process.


Requirements are built and released based on the team’s clear understanding of requirements dependencies, which also drive architecture trade-off decisions. Requirements are dependent on each other when each relies on (and thus constrains) the other.

Smart agile teams analyze development and delivery dependencies to optimize value. Traditional requirements models are useful for dependency analysis and to supplement agile’s lightweight requirements (such as user stories).


It’s All Good

“Agile requirements” isn’t an oxymoron, although it may be a bit of a paradox—in the same way that the concise enables the complex, the small gives rise to the large, incompleteness facilitates the finish, and you must slow down to speed up. Indeed, agile requirements are central to agile planning, development, and delivery.

Author: Ellen Gottesdiener, EBG Consulting, Inc.

Ellen Gottesdiener is a Conference Speaker for the Business Analysis Conference Europe 2010.

At the conference, she will be facilitating a workshop titled Agile Requirements: Collaborating to Define and Confirm Needs and will be presenting a session titled Agile Analysis Practices: So What's New?

EBG Consulting, Inc. principal consultant and founder Ellen Gottesdiener helps business and technical teams collaborate to define and deliver the product customers value and need. Author of two acclaimed books, Ellen works with global clients and speaks at industry conferences. As an agile coach, trainer, and contributor to the agile IIBA BABOK™ agile extension, Ellen is passionate about sharing the value of agile practices for analysis, and the discipline of analysis for agile value delivery. Learn more from her articles, tweets and blog, free eNewsletter and find variety of useful practitioner resources on EBG’s web site.

IIBA UK Conference 2010 - Business Analysis Conference

Like this article:
  12 members liked this article


edward posted on Friday, September 3, 2010 4:23 PM
i am glad that you continue to put forward these thoughts about requirements and agile processes/methods.

many years ago, when i first really understood requirements, i learned that requirements should describe what the client needs are in order for them to solve a problem - whether a small or large problem.

so, requirements are always needed to help guide the solution development of immediate, near-term, and/or long-term program, project, and iteration goals. without requirements [at least a list of goals], it's almost impossible to figure out whether what was delivered realized and/or satisfied any of the agreed upon goals.

how the solution is developed and delivered, whether it's manual, automated, client/server, cloud, embedded or a hybrid of these possibilities, is based on those requirements.

thanks again, ellen for a insightful yet concise article.
edward in dallas, tx

David Wright posted on Tuesday, September 14, 2010 8:41 PM
"Requirements are built and released based on the team’s clear understanding of requirements dependencies, which also drive architecture trade-off decisions."

And that is the fly in the value ointment. You have to install the plumbing before you can have a shower. I am not sure if this is well understood, so I would love to see more focus on this aspect of agile delivery.
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC