One reason I don’t trust change is when that change has no defined end goal. When a change is requested, and the ticket completed, but it then enters a cycle of scope-creep that means the ticket can never be closed.
They often start with something simple e.g. “can you improve the performance of this search”, with a simple tweak – add a JOIN clause to avoid SELECT 1+n queries. In some cases the user acknowledges the improvement, but some users will start pushing new features against the request “because it’s in the same area”. After all, changing the colour of the links on the search page is still part of the same use case, right? And the fact the search is still slow when I use this rare combination of fields means the original ticket wasn’t fixed.
Close it and move on
In some scenarios, it’s easy to be brutal. These are time-bounded sprints, so anything raised must be factored in. This works where features and bugs are interchangeable and represent simply “work to be done”, however they are charged, and let the retrospectives and other analysis worry about whether any particular piece of work is a bug or a feature, so that the team can ensure it’s delivering the best business value.
The definition of done needs to be clear from the ticket (although maybe not to the detail of a SMART objective, it’s worth thinking about that framework). If the provided steps no longer produce an incorrect result, or a speed improvement is recorded, or some other pre-defined success criteria is met, then the ticket is done. Any further discussion is a new ticket. If the objectives aren’t met, it should not be marked as done and the developer should continue work on it.
It’s under warranty
Many software products and projects have a grace period of warranty, where bugs are fixed for free. This is typically useful to resolve conflicts in untested combinations, or volumes, but it can also be used as a stick if the developers aren’t careful. Provided the warranty period is reasonable for the size, complexity and support arrangements within the project, bugs should be fixed to ensure the original scope is delivered. Some customers will however try to extend scope by issuing bug amendments to change scope, under the guise that the bug was raised during the warranty period is therefore should be resolved. After all, bugs should be fixed, but features must be paid for.
Make sure you have a good rapport with your client, and make sure the terms are clear.
Decide now what done means, and how to manage tickets
The last thing you need is to decide this when the tickets that’s blocking the release gets re-opened for the 100th time because the CSS is broken in IE6.
What does it mean to be done?
What constitutes a failure?
Can the software be released as it is?