There's an unproductive anti-pattern where bugs are put into the backlog, to 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 it gets worse: 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 there's some area that needs improvement. 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! (that's the 5th principle of Lean). Kevin Sookocheff writes about 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 may work smarter to avoid them in future work.
It's not that any and all defects are automatically high-priority failures, they're worst when a bug is in a project that's long-closed and forces developers to context-switch back into that system to apply the proper fixes. Whereas defects in a project that's still in-progress don't have the same negative impact, and they never get to represent a festering risk. I mean, still fix those "in-progress" defects immediately, just keep in mind they can also be valuable signals that a team is working at their cutting edge. As long as they learn and adapt it's fine.
But prioritize bugs and invest in avoiding those that come after a project is closed. And definitely, DEFINITELY, don't backlog them.
Top comments (0)