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:
- A set of requirements is created.
- After careful analysis etc the requirements are baselined or frozen.
- As time goes by, the baselined requirements need to be changed.
- 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.
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.
- Venn-diagram-of-requirements-vs-backlog-items: Owned by the author
- Change request type 2: Owned by the author
- Hourglass Shadow: Bill Brooks on Flickr | CC BY NC ND 2.0
Wonderful article! This provided detailed information about project management and how to make use of it. Moreover, I have seen a growing demand for Project management certified professionals. With the help of training providers like http://www.pmstudy.com/, I was able to prepare for my PMP exam in an efficient manner.
One client is in the health care enrollement business, with weekly releases of the enrollment system. Many changes flowed down from federal Government. State and Local changes weekly as well.
But strict architectural, security, and data security controls require full Change Management (ISO 12207).
So agile and change management work hand in hand. This is all implemented thorough formal processes and tools that implement these processes as well as strictly enforce the governance rules
Pingback: Will ITIL survive Agile and DevOps? - Greger Wikstrand
Thought provoking and useful. Thanks.
In my org, we’ve created a Release Train and of the Feature teams is supposed to fix a backlog of CR’s. They have a basic question – each CR is a Small work request essentially and they are looking for an ‘epic’ to tie those CRs to. I can sure enable the PO and scrum team to think but based on your experience, can you suggest what’s a good approach looks like? I’ve thought of tagging each CR to its relevant (other team’s) Epics (more like enablers) just like another user story but that is a team on the train and that structure is not something I can change. Thoughts?
Thanks for taking the time to comment. IMHO, this is a perfect example of how you cannot make one size fit all needs. Basically, such an “epic” would be nothing else but “As a customer I want the following CR:s fixed in the next release: 1, 2, 3, 4, 5 etc so that I will feel inclined to pay you”. My basic objection with the epic / story hierarchy and with user stories even more is that they conflate work items with requirements. Read more about my PoV here.
Very nice article!
Was wondering if you could help in a discussion we have at our work place? Finally we are starting with change management and that brings a lot of confusion.
We have a discussion regarding adding Oracle Datafiles. Here they think that is a change (request) because you make a change on the system. I’m saying it is not because adding datafiles is part of normal operations. Nor are we changing something about the configuration.
Thanks in advance
Good question! There are those that would argue that eg a bug report is actually a change request because someone wants something to be different. Others would say that making something work as specified is not a change. If I withdraw money from my bank account the balance will change but the account will not change.
All these examples show that the whole idea of change depends on perspective and the definition of the system boundary. In the first example, the system is running, executable system that the users encounter every day. In the second example, the system is the specification. In the third example the system is the account balance.
Another perspective on change is that it is something that needs approval and additional expenditure. In that case, the first example is not a change if it is covered by warranty but it is a change if there will be a charge for the change.
Back to your example:
Thanks for the clear explanation! I can use this and take it back to the group 🙂
Thanks a lot
How would a CR affect the original User Story? I am keen on understanding how can we keep a single source of truth for the system requirement. One side question is, can we call requirement and specification as different things? They are used so interchangeably but a CR can be requirement but not specification IMHO