Project Management

If the Requirements Aren't Changing Your Team is Likely in Trouble

From the Disciplined Agile Blog
by , , , , , ,

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Valentin Mocanu
Daniel Gagnon
Michael Richardson
Joshua Barnes

Recent Posts

Disciplined Agile Certification Training Goes Virtual

Videoconferencing Tips - How to Have Effective Calls

Examining the differences between DA and existing PMI materials

Spotlight on Product Portfolio Funding

Spotlight on Optimizing Flow

Categories: Philosophies, Requirements

I often run into people who are concerned about changing requirements, or evolving requirements if you like that term better, on software development projects (or product teams as the case may be). This is typically a reflection of their training and background in traditional software development strategies where changing requirements are usually perceived as a problem.

In agile we consider changing requirements to be a good thing and we even embrace the idea that this will happen.  In fact, one philosophy of Disciplined Agile Delivery (DAD) is that changing requirements are a sign of a healthy relationship with your stakeholders. Changing requirements indicate that:

  • Your stakeholders are interested in what you’re working on
  • Your stakeholders are thinking about what you’re producing
  • There are feedback mechanisms in place that enable your stakeholders to change their requirements
  • It is easy (hopefully) for stakeholders to change their requirements as their understanding of their needs evolve

So how do you support changing requirements in practice?  The Disciplined Agile (DA) toolkit includes the “Address Changing Stakeholder Needs” goal which guides you through understanding and selecting the right strategy for prioritizing requirements changes as they occur throughout the lifecycle.  These strategies include, but aren’t limited to Scrum’s Product Backlog Strategy, a more disciplined Work Item List strategy, or a lean Options Pool strategy.  In regulatory situations you may even want to consider a formal change management strategy.  DAD’s process goal-driven approach enables disciplined agile teams to tailor their strategy to meet the situation that they find themselves in, avoiding the challenges seen with methods such as Scrum that prescribe a single strategy (in this case Product Backlogs) that don’t work in all situations.

And of course, to minimize the pain of changing requirements you will need to adopt disciplined development practices such as:

  • Writing high-quality code;
  • Refactoring your work to keep it of high quality;
  • Continuous integration;
  • and even acceptance test-driven development (ATTD)/behavior driven development (BDD).
Posted by Scott Ambler on: January 15, 2014 04:53 AM | Permalink

Comments (0)

Please login or join to subscribe to this item

Please Login/Register to leave a comment.


A verbal contract isn't worth the paper it's written on.

- Sam Goldwyn