The below diagram is the basic flow that I generally adhere to when talking about when should a bug get fixed or not. This is pretty obvious – and far easier to draw than to write out.
There are of course some subtleties – the devil often being in those details.
Analysis – this is all about analysis. Sometimes it is easier to do. Sometimes someone needs to do some digging to work out the details. That doesn’t change the decision flow – just that you might need to do more work to get to the decision.
Bug definition – internal issues generally really are bugs as there is usually higher communication around what features and changes are and how to handle those within the team. For external issues they could be changes, features or plain old bugs. I assume that that analysis is already done or becomes clear during the process. No matter what type of issue it is – they are all subject to the same decisions. It is often easier to put a feature/change straight onto the backlog for later planning.
The problems with not fixing bugs now:
- One small bug not fixed now isn’t a problem. 100 is. Don’t naively grow the debt by only looking at the current issue in isolation.
- Not fixing 10 bugs may signify a more rapid decline in not fixing other issues as it gets easier and easier to justify not fixing something.
- Not fixing an issue now may underlie a bigger problem.
- Hanging on to issues that you choose not to fix immediately grows the backlog with low priority issues. Generally these low priority issues never get prioritised because… they’re low priority! Be aware of simply growing a long list of things to remember that you’ll always ignore.
- Make sure that if you decide not to fix something that it doesn’t keep coming back. This is even more pertinent if the team find it and the PO decides to fix it later or never but then when someone else finds it nearer your release date – for instance in a hardening sprint – and now it needs fixing. This shows a problem with the initial decision and will cause frustration for all.
Points for bugs – if I plan a bug for a future release I generally consider it a change and want it to be sized. We’re sizing the effort for the release so we might as well get as much data as possible. If you’re fixing the bug before the release then at most size it to determine how much you can take into the sprint but don’t take points for it as the number of bugs you’re creating is part of your velocity and the real velocity should drop due to work that isn’t properly done being done again. The team should acknowledge that.
Learn from the feedback – as in any agile environment – look at what is happening and try to retrospect on why the issue happened and how we could avoid it happening in the future. What documentation or details could have been shared with the client so that they could have known that what they were asking for isn’t a bug? What did we miss in our own process that caused it to be a bug? Sometimes it is too easy to say it was some once off thing but many once off things could also have the same root cause – or the same solution. Dig a little deeper if everyone simply thinks – well that was due to this one deployment specific issue that now we’ve gone through – it will never happen again. Because it probably will happen again – in some other form.