Managing Defects on Agile Projects

This recent Dilbert comic strip reminded me of a situation when a client was raising cosmetic defect as severity 2.

It is often not clear what a defect is and at what level to raise it at (despite agreed severity descriptions) as my example above shows.  And some defects are raised without being related to a requirement. Or defects raised because of a feature being “not user friendly”.

Regardless of the reason and how you label the ‘defect’, I treat all defects the same – it is a piece of work required by the client that needs to be prioritized with other work. So the approach is to put all work (defect, enhancement, new feature etc) into the product backlog. As part of the planning process, the Product Owner will prioritize the items on the backlog for the next iteration and/or release. So if a cosmetic defect is more important (has greater business value) than a new feature, then it should be placed higher so it gets completed first.

Keeping all work in the product backlog, makes planning simpler and helps manage the flow of work. It also ensures the client is in control and be the judge of what is important to their business.

2 Comments on “Managing Defects on Agile Projects”

  1. Chris, if I could add one more thought. Defects are the indication of something gone wrong. Continuous Improvment cannot take place if nothing is wrong. I am a HUGE advoce of quality engineering that causes us to look at why the defects exists to begin with and work to eliminate those conditions. Reducing rework can be almost as valuable as providing a quality product to a client. Preventing defects gets us both.

  2. Doug,

    I agree with your comments. One thing that can assist with a quality product and help detect defects so they are addressed earlier is relentless test automation.

    However, when solutioning deals this is one area this is often not considered or if it is, it is one of the first to be removed from scope to reduce costs to win the work.

    In addition we need to change the mind-shift to bring collaborative testing up front so defects are fixed earlier when it is cheaper to fix which will also reduce rework down the track.


Leave a Reply

%d bloggers like this: