Agile software development teams embrace change, accepting the idea that requirements will evolve throughout a project.  Agilists understand that because requirements evolve over time that any early investment in detailed documentation will only be wasted.  Instead agilists will do just enough initial requirements envisioning to identify their project scope and develop a high-level schedule and estimate; that’s all you really need early in a project, so that’s all you should do.  During development they will model storm in a just-in-time manner to explore each requirement in the necessary detail.      This article addresses the following issues: The agile change management process Freezing requirements during an iteration? Modeling ahead? Why requirements change Prioritizing requirements Estimating requirements Why this is desirable Potential challenges with this approach   1. The Agile Change Management Process Because requirements change frequently you need a streamlined, flexible approach to requirements change management.  Agilists want to develop software which is both high-quality and high-value, and the easiest way to develop high-value software is to implement the highest priority requirements first.  This enables them to maximize stakeholder ROI.   In short, agilists strive to truly manage change, not to prevent it. Figure 1 overviews the agile approach to managing the work items potentially needed to be accomplished by the team (you may not actually have sufficient time or resources to accomplish all items).  This approach reflects the Open Unified Process (OpenUP)'s approach to work management which is an extension to the Scrum methodology's approach to requirements management.  Where Scrum treats requirements like a prioritized stack called a product backlog, OpenUP takes it one step further to recognize that not only do you implement requirements as part of your daily job but you also do non-requirement related work such as take training, go on vacation, review products of other teams, address defects (I believe that defects are simply another type of requirement) and so on.   With this approach your software development team has a stack of prioritized and estimated work items, including requirements, which need to be addressed – Extreme Programmers (XPers) will literally have a stack of user stories written on index cards whereas OpenUP might use a defect tracker such as ClearQuest to manage the stack.  Stakeholders are responsible for prioritizing the requirements whereas developers are responsible for estimating.  The priorities of non-requirement work items are either negotiated by the team with stakeholders or are addressed as part of slack time within the schedule.   Figure 1. Agile requirements change management process.   The "lifecycle" of a typical development iteration: Start.  At the start of an iteration the team takes the highest priority requirements from the top of the stack which they believe they can implement within that iteration.  If you have not been modeling ahead, more on this below, you will need to discuss each of the requirements that you pulled off the stack so that you the team can plan how it will proceed during the iteration.  In short, you will be doing some modeling at the beginning of each iteration as part of your overall iteration planning effort, often using using inclusive modeling tools such as paper or whiteboards. Middle.  The team then develops working software which meets the intent of the requirements, working closely with stakeholders throughout the iteration to ensure that they build software which meets their actual needs.  This will likely include some model storming to explore the requirements in greater detail. End.  The team will optionally demo the working software to a wider audience to show that they actually did what they promised to do.  Although a demo is optional I highly recommend doing it: because working software is the primary measure of progress on a software development project, you want to communicate your team's current status by regularly demoing your work.   1.1 Should You Freeze The Requirements During an Iteration? Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers.  If you do this then any change to a requirement you’re currently implementing should be treated as just another new requirement.   XP and OpenUP support changing requirements during the iteration if you wish to work that way, although doing so may force you to sometimes move some requirements to the next iteration to make room for new requirements introduced during the current iteration.  Both approaches are perfectly fine, you just need to choose the approach which makes the most sense for your situation.   1.2 How Much "Modeling Ahead" Should You Do? Figure 1 indicates that the items towards the top of the stack are described in greater detail than those towards the bottom.  There's a few important things to understand: It's a significant risk to do detailed modeling up front.  The article "Examining the Big Requirements Up Front (BRUF) Approach" addresses this problem in detail. The requirements in the current iteration must be understood in detail.  You can't implement them properly if you don't understand them.  This doesn't imply, however, that you need mounds of comprehensive documentation.  You can model storm the details on a just in time (JIT) basis.  You may decide model a bit ahead.  For complex requirements which are approaching the top of the stack, you may choose to model them a few days or weeks in advance of implementing them so as to increase the speed of development.  Note that any detailed modeling in advance of actually needing the information should be viewed as a risk because the priorities could change and you may never need that information. You just need enough detail to estimate the later requirements.  It's reasonable to associate an order-of-magnitude estimate with requirements further down on the stack, so you'll need just enough information about the requirement to do exactly that.

2. Why Requirements Change

People change their minds for many reasons, and do so on a regular basis.  This happens because:

1. They missed a requirement.  A stakeholder will be working with an existing system and realize that it's missing a feature.
2. They identified a defect.  A bug, or more importantly the need to address the bug, should also be considered a requirement.
3. They realize they didn't understand their actual need.  It's common to show a stakeholder your working system to date only to have them realize that what they asked for really isn't what they want after all.  This is one reason why active stakeholder participation and short iterations are important to your success.
4. Politics.  The political landscape within your organization is likely dynamic (yes, I'm being polite).  When the balance of political power shifts amongst your stakeholders, and it always does, so do their priorities.  These changing political priorities will often motivate changes to requirements.
5. The marketplace changes.  Perhaps a competitor will release a new product which implements features that your product doesn't. 
6. Legislation changes.  Perhaps new legislation requires new features, or changes to existing features, in your software. 

3. Prioritizing Requirements

New requirements, including defects identified as part of your user testing activities, are prioritized by your project stakeholders and added to the stack in the appropriate place.  Your project stakeholders have the right to define new requirements, change their minds about existing requirements, and even reprioritize requirements as they see fit.  However, stakeholders must also be responsible for making decisions and providing information in a timely manner. 

Fundamentally a single person needs to be the final authority when it comes to requirement prioritization.  In Scrum this person is called the product owner.  Although there is often many project stakeholders – end users, managers, architects, operations staff, and so on – the product own is responsible for representing them all.  On some projects a business analyst may take on this responsibility.  Whoever is in this role will need to work together with the other stakeholders to ensure everyone is represented fairly, often a difficult task. 

4. Estimating Requirements

Developers are responsible for estimating the effort required to implement the requirements which they will work on.  Although you may fear that developers don’t have the requisite estimating skills, and this is often true at first, the fact is that it doesn’t take long for people to get pretty good at estimating when they know that they’re going to have to live up to those estimates. 

Smaller requirements are easier to estimate.  Shall statements, such as “the system shall convert feet to meters”, are an example of very small requirements.  User stories are a little larger but still relatively easy to estimate.  Use cases, a staple of the Rational Unified Process (RUP) and the Agile Unified Process (AUP), can become too large to estimate effectively although you can reorganize them into smaller and more manageable artifacts if you’re flexible.  A good rule of thumb is that a requirement must be implementable within a single iteration.  Scrum teams usually have month long iterations whereas XP teams often choose one or two weeks as an iteration length.  Short iterations reduce the feedback cycle making it easier to stay on track.  Successful teams will deploy a working copy of their system at the end of each iteration into a demo environment where their potential stakeholders have access to it.  This provides another opportunity for feedback, often generating new or improved requirements, and shows stakeholders that the team is making progress and thus their money is being invested wisely.

5. Why This is Desirable

This approach is desirable to IT professionals because it enables us to always be working on the highest-value functionality, as defined by our stakeholders, at all points in time.  This is not only a good business decision, it is also very satisfying for developers because they know that their work is actually having a positive impact on the organization.

There are several reasons why this is incredibly attractive for stakeholders:

1. They get concrete feedback on a regular basis.  By developing working software on a regular basis stakeholders can actually see what they're getting for their IT investment.
2. They have control over the scope.  The stakeholders can add new requirements, change priorities, or rework existing requirements whenever they want.  To do so, they merely modify what is currently in the stack.  If the team hasn't gotten to the requirement yet, then it really doesn't matter that the requirement has changed.
3. They have control over the schedule.  The stakeholders can fund the project for as long as they need to.  The development team is always working on the highest priority requirements which are currently identified, and they produce working software each iteration.  The implication is that at various points in the project that the stakeholders should be able to say "OK, this is good enough for now, let's deploy this into production", giving them control over the schedule.  Yes, they will still need to go through a release iteration to actually get the system in production.
4. They have control over the budget.  At the beginning of each iteration the stakeholders can decide to fund the team for as much, or as little, as they see fit.  If the team has been doing a good job then the stakeholders are likely to continue the same level of funding.  If they team is doing a great job then they may decide to increase the funding, and similarly if the team is doing a poor job then they should decrease or even cut funding.  The implication is that not only do stakeholders have control over the budget, they can also treat their IT investment as a true investment portfolio and put their money into the project teams which provide the greatest ROI.

In short, with this sort of approach stakeholders are now in a position where they can govern their IT portfolio effectively.

6. Potential Challenges With This Approach

Traditionalists often struggle with the following issues:

1. It isn’t clear how much the system will cost up front.  As the requirements change the cost must also change.  So what?  The stakeholders have control over the budget, scope, and schedule and get concrete feedback on a regular basis.  In this situation stakeholders don't need an estimate up front because of the increased level of control which they have.  Would you rather have a detailed, and very likely wrong, estimate up front or would you rather be in control and spend your money wisely?  The approach I’m describing enables the latter, and according to the 2007 Project Success survey, that's what the vast majority of people desire.  Furthermore, with a bit of initial requirements envisioning you can easily gather sufficient information about the project scope to give a reasonable, ranged estimate early in the project.
2. Stakeholders must be responsible for both making decisions and providing information in a timely manner.  Without effective stakeholder involvement any software development is at risk, but agile teams are particularly at risk because they rely heavily on active stakeholder participation.  Someone needs to be the final authority when it comes to requirement prioritization.  In Scrum this person is called the product owner.  Although there are often many project stakeholders – end users, managers, architects, operations staff, and so on – the product owner is responsible for representing them all.  On some projects a business analyst may take on this responsibility.  Whoever is in this role will need to work together with the other stakeholders to ensure everyone is represented fairly, often a difficult task. 
3. Your stakeholders might prioritize the requirements in such a way as to push an architecturally significant (read devastating) requirement several months out.  For example, the need to support several technical platforms or several cultures will often cause significant havoc to projects teams which are unprepared for these changes.  My experience is that the order of requirements really doesn’t matter as long as you do two things:  First, keep your design modular and of the highest quality possible via code refactoring and database refactoring.  Second, just as you do some initial requirements modeling up front you should also do some initial architectural modeling up front.  This model effort should still be agile, it’s surprising how quickly you can sketch a few whiteboard diagrams which captures a viable architectural strategy for your team. 
4. You still need to do some initial requirements modeling.  The requirements stack just doesn't appear out of nowhere, you're still going to have to do some high-level initial requirements modeling up front.  This is a lot less than what traditionalists will tell you what you need to do, but it's a bit more than what some of the extremists might like to claim.  You need to do just barely enough for your situation.

7. Recommended Resources

• Active Stakeholder Participation  
• Agile Analysis
• Agile Requirements Modeling
• Agile Requirements Best Practices
• Best Practices for Agile/Lean Documentation
• Certified Scrum Master Workshop
• The "Change Prevention" Anti-Pattern
• Examining the Big Requirements Up Front (BRUF) Approach
• Inclusive Modeling: User-Centered Approaches for Agile Development
• Initial High-Level Architectural Envisioning
• Initial High-Level Requirements Envisioning
• The "Model a Bit Ahead" Pattern
• Overcoming Common Requirements Modeling Challenges
• The Process of Database Refactoring
• Rethinking How You View Requirements Management
• Rethinking the Role of Business Analysts
• The Unchangeable Rules of Software Change (Brad Appleton, Robert Cowham, and Steve Berczuk)

 

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

8. Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here.