Project Management

Agile Requirements: Oxymoron?

Ellen is is an expert in lean/agile planning and analysis; product backlog discovery, refinement and management; and collaborative techniques. She is the author of three books, including Discover to Deliver: Agile Product Planning and Analysis. Ellen works with global clients, writes widely and speaks at industry conferences.

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?

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 …

Please log in or sign up below to read the rest of the article.


Continue reading...

Log In
Sign Up

"Nothing defines humans better than their willingness to do irrational things in the pursuit of phenomenally unlikely payoffs."

- Scott Adams