This article addresses the following issues:
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
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
The agile change management process
Why requirements change
Why this is desirable
Potential challenges with this approach
1. The Agile Change Management Process
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
maximize stakeholder ROI.
In short, agilists strive to truly manage change, not to prevent it.
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
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.
1. Disciplined agile
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
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?
|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.
People change their minds for many
reasons, and do so on a regular basis. This
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.
They missed a requirement.
A stakeholder will be
working with an existing system and realize that it's
missing a feature.
They identified a defect.
A bug, or more importantly the need to address the
bug, should also be considered a requirement.
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
active stakeholder participation and short
iterations are important to your success.
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
The marketplace changes.
Perhaps a competitor
will release a new product which implements features
that your product doesn't.
Legislation changes. Perhaps new legislation
requires new features, or changes to existing features,
in your software.
"You don't have to change, survival is not compulsory."
-- Edward Demming
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
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
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.
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
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
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
There are several reasons why this is incredibly
attractive for stakeholders:
- 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.
- 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.
- 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
- 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
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
- 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
- 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
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.
- 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
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
- 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.
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
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
(TDD). The Object Primer also includes a
chapter overviewing the critical database
development techniques (database refactoring,
legacy analysis, and
database access coding) from my award-winning
Agile Database Techniques
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
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
architect, and then
design your system in an agile manner.
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
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.
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.