Defect backlogs — why we don’t need them

A zero-defect backlog is a software development approach where all known bugs are prioritised and addressed before new features, aiming to maintain a backlog free of defects. Zero-defect backlogs can be applied not only to software engineering, but also to manufacturing in the sense that “zero-defect” is an approach taken by the organisation as a whole. It can also be described as a mentality taken on by the organisation where measures are taken to not have any backlog dedicated to defects — a place often known as where defects are forgotten and die off.

A Zero-defect backlog approach to software engineering fosters a culture of quality, reduces the cost and time required to fix defects, increases innovation, improves customer satisfaction and promotes continuous improvement.

Teams who adopt a zero-defect approach prevent wasted resources in projects, and the process can be achieved in different ways. Since we are focusing on software development, let’s see what software development teams do to follow this approach. The literal term “zero-defect backlog” can mean one of two things:

1. No defects ever occur in the project

2. Defects or bugs are fixed at the time of detection

We can then assume that defects are never put into a backlog, and are fixed at the moment they are detected. By fixing the bug on the spot, there is no lag in getting it fixed. The defect also does not lose relevance, as team members are still in the same context (iteration in which a feature is developed). However, if the bug were to be triaged, prioritised and put in a backlog, there would be a loss of context by all team members (”who remembers what this bug was all about?”), and then would have to take the time to re-familiarise themselves with the bug in question.

Within software development teams, we will have bugs that are classified in various ways — whether by priority, severity or area of the application, among other classifications. However, there is a classification that is not discussed enough: The “bug lost in the backlog” classifications. The bug workflow often works like this:

What’s missing from here is that teams will put bugs in backlogs — not all the time. But when feature development is tied to a deadline, bugs that are not showstoppers are put into a backlog, assigned to a priority level and then dealt with later through a backlog grooming session. During that session, everybody needs to remember what these bugs are about, especially if they’ve been raised more than a sprint ago.

Between grooming and fixing these bugs, bringing them into context alone takes a significant amount of time depending on how long ago it was raised. If teams continue this way of doing things, the types of bugs in the backlog, which wastes further time still, can kill the team’s productivity.

Bug backlogs are clearly a bad thing, and kill productivity, but what specifically do bug backlogs do that hurts the team? It depends on the kind of “bug in the backlog” classification given. Here are several kinds, and the damage they can cause to teams. In practically all cases, these should be fixed on the spot to avoid the damaging consequences (mostly noise and distraction):

All of the above cases can be avoided if teams were to fix bugs on the spot. One could argue that dropping everything to fix a bug is costly by changing context, but fixing it any time later than now would cost much more in the end.

If we want to put a relative cost of detecting and fixing bugs, the graphic below can give an idea of how much it costs in each phase of development:

• Requirements: When a bug or defect is caught in this phase, the team can easily make changes to plans, and modify requirements as needed. Also, no code has yet been written.

• Design/architecture: The cost rises as plans are made around architecture, if changes need to be made at this phase of development due to a bug or defect.

• Coding: As more code is developed to create a feature, the more complex it becomes to fix an issue. However, as the developer is still in context, costs remain relatively low.

• Testing: If testing is treated as a siloed-off phase of development, fixing a bug becomes more costly, as a developer then needs to switch context and reproduce the issue.

• Deployment/maintenance: At this phase of development, the feature has already been released, and poses a greater risk to fix bugs. Not to mention putting the reputation of the team at risk.

If quality processes are implemented at each phase of development (and not as a separate testing phase) these risks can be mitigated as long as fixes are provided on the spot and not put in a backlog.

If a team adopts the zero-defect approach, what can they do with this extra time? Sure, it reduces noise and clears mindspace. But what does it mean for each team member?

1. Quality assurance/test engineers

• Less maintenance on test automation means more time to improve the product — i.e. exploratory testing, extending test coverage, etc.

2. Software developers

• While in context, less time to find related code and re-familiarise means more time to improve other things — performance improvements, or moving ahead on other initiatives

3. Project managers

• One less backlog to manage

4. Product owners

• Less overall re-work — like having to redo the foundation of a house

5. Everybody

• Common: Less loss of context

• Fixing early avoids the need for a bug-fixing sprint

The bottom line for a zero-defect approach to software development: it is one potential avenue to reduce the amount of time wasted on simply having a defect backlog. Fixing bugs as they occur (and as early as possible in the software development process) reduces the cost related to detecting and fixing bugs later. Loss of context, and increased complexity as time elapses are some of the factors contributing to this increased cost. With the zero-defect approach, and eliminating the bug backlog altogether, teams may find an additional tool in enhancing project quality and velocity.