News Stay informed about the latest enterprise technology news and product updates.

Agile requirements: A conversation with author Dean Leffingwell, part 1

Requirements management has been said to be the most challenging part of software development. In Agile environments, changes in requirements are expected and embraced. But doesn't this wreak havoc with a schedule? Dean Leffingwell, author of Agile Software Requirements – Lean Requirements Practices for Teams, Programs, and the Enterprise, answers this and other questions in this first part of a two-part interview with SSQ site editor Yvette Francino.

In his book, Agile Software Requirements – Lean Requirements Practices for Teams, Programs, and the Enterprise, Dean Leffingwell provides insights and advice on how to tackle the challenges surrounding requirements for software development teams operating in Agile environments. In Part One of this two-part interview, Leffingwell talks about the differences between Agile and traditional requirements practices and gives advice what to look for in Agile requirements tools.

SSQ: Can you start by telling us some of the differences in how requirements are gathered and managed in an Agile environment vs. a traditional waterfall environment?

Dean Leffingwell: The main difference in requirements gathering in agile vs. traditional development is that the itemized and estimated “backlog” is now the “vision placeholder” for upcoming epics, features and user stories, and this lightweight form typically replaces the traditional marketing/product requirements document. In addition, further requirements elaboration (software specifications) is deferred until the iteration or release boundary in which that functionality is implemented. This reduces requirements inventory, and work in process (work is done serially) and provides additional degrees of freedom as to how the vision can be met in the implementation.

In addition, the XP-derived “user story” is now the primary software requirements proxy, and the user voice form of “As a [role] I can [system activity] so that [business value]” helps developers and testers better understand the user, their role, and what value that the various user/system activities provide in their personal or business setting. This is a great requirements construct because they are small, testable and deliver value, thereby facilitating incremental development.

SSQ: Are there times, perhaps because of regulations or fixed bid contracts when it’s important to have requirements decided upon and frozen early in the process? In such cases, is using an agile methodology still an option?

Leffingwell: If there were a fixed price project with theoretically perfect requirements, I’d still use agile development because 1) value delivery starts immediately and incrementally, why wait? And 2) the requirements weren’t perfect anyway, might as well find out sooner, rather than later, and 3) as the system is delivered, the customer’s needs will likely evolve to new requirements anyway, and 4) why leave the risk of system integration and actual fitness for use until the end of the project? Seriously, I no longer have any idea as to why anyone would not want to use agile on ANY type of software project, unless the adrenalin rush of leaving all the risk until the end is some pernicious form of business addiction.

SSQ:  What do you think are some of the key things that should be looked for in a Requirements Management Tool to be used in an agile environment?

Leffingwell: 1) Lightweight, facile, always available and directly supportive of the agile team’s needs for backlog management, story writing, task identification, ownership, estimating and status tracking, sprint burndown, persisting acceptance criteria, etc.

2) Scalable to the enterprise needs with hierarchical stories (or epics, features, stories), progress burn down and or burn-up at the feature, epic and program level (multiple team aggregate reporting), and support for portfolio management and road mapping.

SSQ:  Agile teams are known to embrace change. However, when requirements change mid-stream, especially on a large project, it can mean changes to schedules and create other issues. Are there some guidelines that should be in place or do product owners have full reign to change requirements throughout the project’s lifecycle?

Leffingwell: Well, requirements always change, and schedules and budgets therefore must too, whether we admit it or not. We should just get over it and move to a more flexible development model that embraces change. That would be Agile.

SSQ: What do you think are the most important requirements practices that an agile team should put in place?

Leffingwell: Start with:

  • Have short, disciplined time-boxed iterations of no more than two weeks.
  • Keep a short, but well defined backlog ready.
  • Apply user stories.
  • Write the acceptance test before the code.
  • Have and apply a Definition of Done.

At enterprise scale, there’s far more to it than that, but you can’t scale non-Agile teams anyway, so that’s always the right place to start.

Find out more about Agile software requirements, particularly in Scrum environments, in part two of this two-part interview with Dean Leffingwell.


Dean Leffingwell is author of the book, 'Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise,' published by Addison-Wesley Professional, ISBN 0321635841, Dec. 2010. For more info please visit For a sample chapter, Chp#2, "The Big Picture of Agile Requirements," please visit the publisher site:

(Copyright 2011 Pearson Education, Inc.)

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.