Agile Requirements Change Management

1. The agile change management process
   • Freezing requirements during an iteration?
   • Modeling ahead?
2. Why requirements change
3. Prioritizing requirements
4. Estimating requirements
5. Why this is desirable
6. 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 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.

The “lifecycle” of a typical development iteration:

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 stakeholdersthroughout 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 team, 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:

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.

3. Prioritizing Requirements

New requirements, including defects identified as part of your user testing activities, are prioritized by your stakeholders and added to the stack in the appropriate place. Your 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 stakeholders – end users, managers, architects, operations staff, and so on – the product owner is responsible for representing them all. On some teams 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), 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 team 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 initiative 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 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 scope to give a reasonable, ranged estimate early on.
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 stakeholders – end users, managers, architects, operations staff, and so on – the product owner is responsible for representing them all. On some teams 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 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.