Change Request Process for Agile Development

Table of Contents

Why change requests appear so often

The reality of building anything in agile is that the work board looks fine until somebody drops a new request in Slack that contradicts half of what you thought was approved. I have had tickets labeled as done sitting in Jira, and then suddenly a product manager says the wording on a button feels wrong, and now the sprint demo is blocked because what counts as done changed underneath us. Honestly, it feels like trying to fix a bike tire while pedaling downhill. 😛

A change request is just a formal way to tell the team hey we need to tweak this. It sounds obvious, but writing down exactly what changed is the difference between chaos and being able to track why the original acceptance criteria shifted. The first time I worked on one of these requests, we had no template. People just threw messages in chat and by the end we all disagreed on what had actually been asked. That was the most confusing week, because when we merged the branch, QA thought we had ignored half the request.

So usually now I start with the bare minimum info a beginner would need. One short sentence about what needs to change, one note on why it needs to change, and one checkbox about urgency. That way, even if nobody reads the details, they at least know whether it’s urgent or not. Simple text tables in a document help organize it. Something like:

This makes it hard for someone to later say they misunderstood. ¯\_(ツ)_/¯

How to capture the request clearly

The problem I kept running into is that people describe changes like they are telling a story instead of giving instructions. I have emails that say things like I clicked on the profile page and the vibe felt boring so can you add something. That is not a reproducible request. It’s like asking a mechanic to fix the sound your car makes when it is sad.

What helped was forcing every change request into a simple template inside our project management tool. I tried Trello, Jira, and even just Google Docs tables. It does not matter much which, but the key is to have the three main sections always there: What is changing, How it affects the user, and What sprint it might land in. The first week we used it, there was some groaning and people complained about the extra typing. But after two or three sprints, suddenly demo day had fewer surprises. That was a relief.

If you are completely new to this, think of a change request like a recipe correction. Imagine you already wrote instructions that said bake for 20 minutes, but then someone actually tried it and the cake burned. Now the correction is literally cross out 20 and write 15. You would not write a whole story about how the cake was kind of meh and the smell wasn’t ideal. That is the difference between feedback and a request. Feedback is feelings, a request is instructions.

How tools handle requests differently

I have switched request tracking systems three times in one year. Each one failed me in a different way, which is why I laugh when anyone says tool choice doesn’t matter. For example, Asana let me set up tasks super fast but tagging priorities was messy, and people kept forgetting to set a due date. In Jira you can set custom fields, which sounds powerful, but then you end up clicking five dropdowns just to log a one line change. Trello was the most visual, but sometimes cards just stack up on each other and nobody knows which are new or old.

Biggest tip I learned was to attach screenshots every single time. A request with no screenshot usually wastes an hour of back and forth messages. On the other hand, a screenshot with a red box drawn around the thing to change cuts straight to the point. Beginners who do not draw boxes can still just highlight or circle. Nothing fancy needed.

If you want to read more about actual tool options, Atlassian has some details on Jira at atlassian.com. But honestly, whichever platform you pick, the core is making sure your change request has a predictable place to live. Otherwise it floats around like lost socks.

Who approves the change request

This is the part that gets messy. In theory, the product owner owns the backlog and therefore officially approves changes. In practice, I have seen developers merge requests on the fly just to unblock testing, and then a week later leadership says we shipped something without approval. It is very human. Nobody wants to block progress, but nobody wants to be left out either.

My workaround was to add a yes or no field in the request itself saying approved and assign it to one specific person. That way, even if developers implement early, the field stays blank until someone fills it. We had funny moments where the implementation shipped and only then did the field get marked approved, like backdating a permission slip. Not perfect, but at least the record shows it happened.

If you are new, try to identify just one approver. If you have two or three people fighting over it, requests bounce back and forth endlessly. Beginners often overlook this and suddenly discover that two managers gave two different answers. Not fun.

How the team communicates the update

Another stumbling block for beginners is assuming the request is done just because the code merged. Nope. Someone actually needs to say hey this request was completed, please check it. Otherwise it sits forgotten. I learned to add a Done comment on the original request card. Simple. A tiny notification pings the requester, and they can validate it right away.

One rookie mistake I personally made was closing requests without telling QA. I thought Done was obvious. Instead, testers had no idea what to test or when, because the code was just silently sliding into the main branch. Ever since, I over communicate. Even if it feels like obvious spam sometimes, better than backlog ghosts.

Often teams link pull requests back to the original change ticket. If you are unsure how, just paste the tracking number in the commit message. That way, when someone reviews code history, they can click right back to the description of what changed.

Handling urgent versus nice to have

Up there with unclear instructions, the biggest problem we had was urgency confusion. Somebody would log a request at 10pm and expect a fix by morning. Another request sat for weeks because nobody realized the customer was upset about it. Simple solution I found is a column or tag that literally says Urgent or Later. Nothing fancy.

We even color coded them on a wallboard once. Red for urgent, green for nice to have. It looked silly but you could walk past the board and immediately see if too many reds piled up. That alone started some good conversations about whether we actually treat urgent seriously or just say everything is urgent. 🙂

Beginners often get overwhelmed here because the word urgent feels bossy. Remember, urgent just means it has a business impact if delayed. Nice to have means it may help but no one is on fire without it.

When requests contradict previous work

This is the painful reality where you finish implementing a design change, only for a stakeholder to say actually we want it back the old way. I felt my soul leave my body the first time a full sprint worth of styling got ripped out. But it happens because agile is built on change, and sometimes users respond differently than expected.

When this happened to me, I started documenting the before and after in a single table:

This way it was obvious we had already switched once. The table helped new folks on the team understand we were not bad at following directions, we were literally pivoting back and forth.

I do not have a magic fix, but keeping clear logs of requests means at least the history shows you were not making random decisions.

How requests turn into learning

After all the juggling, the thing I appreciate most is how each change request shows where our original planning missed something. It can be exhausting, but it is also a record of real user reactions. Every time I reread old requests, I laugh at how seriously we debated button colors or text labels. Each one maps to a tiny story of a bug, a misunderstanding, or just someone trying to make the product slightly better.

In the end, that pile of tickets is less about process perfection and more about living proof that software is never done, just constantly corrected until it works well enough for the humans using it.