It's an unproductive anti-pattern to put bugs into the backlog, where they just grow old and fester. It's really time to stop that.
I say fester, because a backlog of bugs is anti-lean, anti-agile, and a giant waste of resources: It's a waste of time to groom what isn't going to be worked on soon anyway, it's a waste of mindspace to carry them around in someone's head, it's a waste of time to manage which to pull in and which to ignore for another 6 months, they're just a waste of time!
But that's only half the issue: They also represent an immediate and growing risk. If bugs come in and they're just… part of the workflow, then you're ignoring a clear signal that some area urgently needs improvement. There should be angry customers waiting for this bug to be solved, and who's to say what bug or set of bugs will soon conspire to cause a catastrophic outage? The bugs you know about can just be the tip of the iceberg.
To top it off they also ruin predictability because they're unplanned work. So they threaten your plans too. What more reasons are needed to take them seriously?
So how many bugs are acceptable then? None! Zero bugs. Pursue perfection! (incidentally that's the 5th principle of Lean). Kevin Sookocheff writes about his "Zero Bug Policy" as a way to drive towards 0 bugs. And when bugs do happen, use them as opportunities to reflect on how we can work smarter to avoid them in future work.
This attitude forces a nuance, because not all defects are automatically high-priority bugs. What we really need to urgently react to are bugs in features developers have context-switched away from. But if you find a defect in a feature that's still in-progress then it's not really a bug in the urgent sense.
So be clear on what is a bug, and both prioritize solving every one of them immediately and identify ways of working that reduces the rate of bugs. And definitely don't backlog them.
Top comments (0)