To Change or Not to Change
A Helpful Guide for Navigating Change Requests
Do you ever stay awake at night thinking if that discussion you had at work this morning was a bug, a feature, or a joke? No? Yeah, me neither. I was just asking for a friend.
So, hypothetically speaking, if I were to stay awake at night thinking about how to best organize the new information coming my way during a project, I would definitely try to categorize it so it makes sense for every person involved. To get everything in order, the guide below is my secret helper.
Sometimes, they are not bugs
If you’re still reading this article, I’m pretty sure you’ve heard the phrase, “it’s not a bug, it’s a feature.” If you haven’t…I want to know the address of the rock you’ve been living under. Jokes aside, sometimes what stakeholders or clients see as bugs are actually features.
Since all projects are different, there’s no “one size fits all” approach you can use to make sure this type of a change request is not lost, while also protecting your product and your team’s work. But you can always try to:
- Check initial business/technical requirements. Did it cover that particular case?
- Check your product’s end-to-end flows. Does it make sense in the overall behavior?
- Is it in any way a blocker for the customer or any of the main journeys?
- Could it be a standalone change request or it requires effort from other perspectives (technical, legal, others) as well?
These questions can take you in all sorts of directions, but this is what we do– we put things into perspective and then set them where they belong. Based on the answers, you can see if this change request is, indeed, a bug, if it can block your product’s normal flow, if it can be set aside after the MVP is all done, or leave it to grow old in the backlog.
Sometimes, they are bugs
If the answer to the first question above is “yes,” then congrats, you have a bug! There are so many causes for a bug to exist, and one of the quickest ways to check if it could have been avoided is to go back to the roots. And by “roots” I mean the initial requirements. If it does not act as written, chances are it’s a bug. If all clues lead to a different cause…well, by now you get the point.
The important takeaway here is: if it’s not an actual change to be introduced into your product, resist the temptation to log it as one. Every decision in your product has a logic behind it that makes sense from a business perspective, a technical perspective, a security perspective, and so on. Any change done to it that’s not well documented will cause head scratches later on, especially if the owners of the product end up changing. As somebody who has inherited a product, believe me, this is important.
Sometimes, they are merely improvements
If I buy a bread machine and expect it to make pancakes, you could say I should have read the manual and checked the product’s functions. It’s not the manufacturer’s fault that I have misplaced expectations, but they could improve their bread makers based on my suggestion. This would be what we call an improvement: a thing that makes something better or is better than something else.
While in theory an improvement should be different than a change request, it’s rarely differentiated in any of the tools used by development teams nowadays. It is still advisable to track it as a separate type of requirement because it adds into the original functionality, not replacing it, and it does come with its own benefits:
- Easier to understand and implement (has a very good requirements basis)
- If someone changes their mind and doesn’t want this improvement anymore, it’s easier to remove it than to add a new (or the old) solution
- It will really make stakeholders happy
One of its main characteristics is that an improvement is rarely a top priority, and you can take your time gathering all the requirements and planning it for future iterations.
Sometimes, they’re just somebody’s whim
It may not be nice to say this, but as BAs/POs we often have to defer changes to the products we’re working on that are merely somebody’s whim. We’ve all had that one stakeholder who believed their opinion is the best selling factor. So, we had to do market research, try and see how the change would apply to our product, and so on.
Don’t underestimate a whim, though. What might seem superficial at first could lead to new discoveries of ways to improve your product and your customer’s experience. Based on its characteristics, keep this whim close until you have enough time to spend researching it. Of course, this only works if you are in the type of situation where you can say “no” to that somebody.
Sometimes, they are just workarounds
If there is a workaround for a situation encountered in your product, you might have just uncovered a new problem. Or a new solution.
Usually, a workaround means there is no blocker, but you might find yourself in a situation where some other people, teams or even stakeholders have a bit more work to do on the side to cover it. Sometimes it is possible for them to do the job, other times it’s just not an option. This might be the difference between an urgent and critical change request or a backlog one. You’ve got it from here!
Sometimes, they are just change requests
Change is inevitable and it’s something we’ll probably never get rid of. Also, change is something we might not want to get rid of. What we can do is make sure the change is documented and understood, because it will usually involve more than just adding code and pieces of functionality.
A well-intended change request can change everything you thought you knew. Moreover, compatibility to everything else already implemented is a must, so enjoy the new work!
Sometimes, you have no idea what they are
Is it a bird? Is it a plane? Is it a change request?
If it doesn’t quack like a duck but it’s urgent, chances are somebody will have to solve it and you might need to cover all the requirements. Be mindful that it’s important to track and document any change to the system. So even if you’re on fast forward and have no idea what your “it” is, make sure it’s ready, and then go back and stress some people out who might help you add the change into a category. Maybe even one of the above?
It might take a while, but every request has a category, and it’s only a matter of time until you discover it.
Final thoughts
In theory, the role of a business analyst is slightly different from the one of a product owner. In practice, however, you might find yourself covering more than you bargained for, hence why this list contains general advice and notions so you can sort through them.
You might already have a very good idea of what your role is in your particular project, in which case I am very happy for you. But if you don’t, the tips from this article could be helpful. The main takeaway? Document everything!
