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.

Planning

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.

Developing

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.

Delivering

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.

Resources

• “A View to Agile Requirements” article explaining the Big-View, Pre-View, and Now-View of agile requirements
• “Agile Requirements by Collaboration” article explains how agile teams collaborate to deliver a product roadmap, release plans, and more
• “Managing Analysis Debt”, article with Mary Gorman in Better Software explores that you can incur debt in over- or under- investing in analysis
• The experts take on agile analysis (Modern Analyst interviews, including myself and six others)
• Wiki page for the agile business analysis knowledge base
• Fun mini video on agile business analysis