WHITEPAPER – Agile Requirements is 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.

If you want to learn more about the agile method of developing requirements and how ‘traditional’ requirements practices are adapted on agile projects, then join trainer Ellen Gottesdienerat an an upcoming FREE webinar on October 13, 2010 <click here>.

** Thank you Ellen for allowing me to share this great article with The Agilista PM readers. Ellen Gottesdiener is the Principal Consultant and Founder of EBG Consulting, Inc..  She helps business and technical teams collaborate to define and deliver products customers value and needs. Ellen is an internationally recognized facilitator, coach, trainer, author, speaker, and expert on requirements development, product chartering, retrospectives, agile requirements, and collaborative workshops.  And she is the author of two acclaimed books (Requirements by Collaboration and The Software Requirements Memory Jogger),

* * * * * * * * * * * *

Like what you read? Get hot news on the Agile-Lean community, upcoming webinars, case studies and tools you can use to help you be as Agile-Lean as possible….delivered right to your inbox weekly.  No spam or junk mail. You can unsubscribe at any time.