Agile Requirements Change Management

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:

1. The agile change management process

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 disciplined 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 Disciplined Agile Delivery (DAD)'s approach to work management which is an
extension to the Scrum methodology's approach to requirements management (read about other agile
requirements prioritization strategies). Where Scrum treats requirements like a prioritized stack called a
product backlog, DAD 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 DAD 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. Disciplined agile requirements change management process.

1. 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.
2. 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.
3. 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 DAD 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?

1. 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.
2. 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.
3. 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.
4. 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.

The bottom line is that if you try to "freeze" the requirements early in the lifecycle you pretty much guarantee
that you won't build what people actually need, instead you'll build what they initially thought they wanted.
That's not a great strategy for success.
"You don't have to change, survival is not compulsory."

-- Edward Demming

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 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.

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.

- See more at: http://agilemodeling.com/essays/changeManagement.htm#sthash.hyHuBfXv.dpuf