Agile Change Requests

There are change requests and then there are agile change requests. Now, I hear some of you saying to yourselves: “He is crazy, there is no such thing as ‘agile change request’!” You are right, partly, I agree that agile methods were designed to avoid change requests. But! All change requests are not created equal and should not be treated the same way. In this post I will describe two major types of change requests as I see them and why you need to treat them differently in agile software development. Hopefully, after reading this you will have a better idea on how to handle change requests in agile methodology.

Change Requests in Traditional Software Development

Let’s start with a small history of change requests and how they were used in what I sometimes call “traditional software development”. Traditional software development projects often work like this:

1. A set of requirements is created.
2. After careful analysis etc the requirements are baselined or frozen.
3. As time goes by, the baselined requirements need to be changed.
4. The person wanting to change something needs to create a change request (CR) which is then handled by a change control board.

The idea is that a stable set of requirements will help prevent scope creep and lead to a good solution being delivered on time and on budget. Unfortunately, this does not seem to work. Any realistic sized project will have a requirements churn that might seem insignificant over a short period but which adds up to major scope changes over the life time of the project.

Why We Need Requirements

Before we continue, a brief reminder of why we need requirements and why we need to track them. Here are some things that we can do if we have proper requirements management:

• Plan and follow-up on releases, sprints and iterations.
• Produce documentation such as user manuals, administration manuals, statements of compliance (SoC), statement of verification (SoV)
• Manage test cases and test execution

And of course, using some form of requirements has other advantages such as being able to claim to the customer that we are working on something they asked for as opposed to something we just dreamed up.

The Role of Change Requests in Non-Agile Projects

But wait, you say, why should we treat change requests any differently from bugs or requirements? Are they not all just some way to express that a stakeholder wants things to be different from how they are now? (At this point, you might want to read my post on backlogs.) Well, there is a big difference. A change request implies that the customer changed their mind and want to change the contract. This means we can make them pay extra for a change request. A bug implies that we did not deliver what we promised to deliver. This often means that we need to give a discount to the customer. That would of course depend on the contract etc.

Many projects are under financed. Because many customers make mistakes when procuring new solutions they will accept a bid which has less than 50% likelihood of delivering on time and budget. The supplier knows this but plans to use change requests to make up for the loss. Ouch, we have set the stage for an adversarial relationship between the supplier and the customer.

Agile Change Management and Agile Change Requests

Enter Agile Software Development. Agile methods “embrace change” and “surf the edge of chaos“. You have heard all the slogans but a fundamental difference between Agile software development and traditional software development is that it sets the stage for a collaborative relationship between the customer and the supplier, a collaborative business experience. There are naturally many different contract models for agile projects but charging extra for change requests is probably not one of them – unless someone is doing fake agile.

Here, Agile has a better chance of avoiding this problem. With a proper Agile contract, you would pay per team per week and you as a customer would decide what they work on by prioritizing the backlog regardless of the types of backlog items on it.

Because Agile Software Development embraces change it is recognized that the requirements specification changes all the time. Only the actual work in progress is protected from change, unless emergency procedures are called on. It would seem that there is no longer a need for special change management. But there is.

Two Types of Change Requests in Agile Methodology

Imagine an hourglass, in the top half of the hour glass are all the customer requirements etc (also known as the backlog). The development team (the narrow section of the hourglass) slowly but steadily turns these requirements into an implementation and the requirements settle into the implemented requirements lower half of the hour glass.

Any change request related to the unimplemented requirements, in the top half of the hour glass, are easily handled by agile process. As soon as you have changed or re-ordered some of the “sand” in the upper half the change request is completed and can be closed. For traceability, you might want to keep a note like “changed from previous version on request by Bill” or something like that. But in Agile Software Development, this is not an Agile Change Request.

Changes to the Implemented Requirements — Agile Change Requests

Let’s have a look at the lower half of the hour glass. Changing things here means removing some of the “sand” from the lower section and putting some new “sand” in its place. As soon as you have completed that operation, just like in the case above, the change request can be closed. Sounds like the same process, right?

In the first case, we change the vision of the product which is something imaginary anyway. In the second case, we change the product itself; we make a tangible change. In the first case, we can more or less imagine that it never happened. In the second case, we need to know that we have a before and an after. For instance, if a customer calls to complain about the change we need to be able to tell him or her that we have made a change and that the change is by design and not a mistake. We need the traceability.

Effectively, this second type of change request will require that we put two items (or more) in the backlog. The new requirement(s) and the change request itself. The change request will be completed over one or more sprints as each constituent requirement is implemented. When the new requirements are completed they move down in the hourglass. When the change request is completed, it is no longer needed except for historical or statistical purposes.

Conclusion

Carefully managing requirements enables us to know exactly which requirements go into which version of our software. Changes that affect the product and not just the vision of the product are harder. Therefore, they need to be managed. Luckily, Agile methods can handle this through the backlog — we just need to let go of the idea that the backlog is only for user stories. The backlog is a list of things that need to be done, and agile change requests might need to be done.

This post was updated on 2013-11-24 with minor editorial changes.