My team has received a request for customer to change the background color in some parts of a legacy app we are upgrading. It is important for the customer to have all change requests properly sorted out to: Legacy Bug, New Feature Bug or New Feature, so that they can easily create a report for release that will show a list of fixed bugs from the legacy app and separately a list of new features that were added. And to be able to ignore the list of fixed bugs that were came up during new feature implementation.
So how do you treat such requests in your projects? Specially in cases where you have a legacy app to fix/improve meaning you don’t have a feature request to link this change to. Do such requests maybe fall in a different category?
Unless there’s a reason to call it something else, I’d list it as a New Feature. It might be a very small feature, but it’s still technically a feature. The customer wants this part of the app to be red instead of blue. That’s a feature.
Here’s how I look at it:
You promised them red background and they got blue background - New Bug
They want a background that’s different from the default - New Feature
Also any change is a feature - whether you add stuff or modify existing.
Keeping track on what is what helps you communicate to the customer the priority and time allocated for each type. Sometimes they prioritize fixed of old stuff, sometimes new stuff is more important.
We participate in creating software solutions, maintaining them… and sometimes closing them and transferring them. Testing can activities in all the places of the application life cycle.
Thank you both for your answers. I am on the same page.
What helped me yesterday to decide it should be a feature was thinking about release notes and how we will formulate those. So for the change of color, if we list it as bug we can’t really say that the previous color was wrong. But if we list it as a new feature, we can state the reason for changing the color i.e. to give more contrast, which is added value to the software.