Agile Q&A: What about defects?

In my previous post, “Agile Q&A: Are there types of User Stories?” I discussed the difference between User Stories, Non-User Stories, and Spikes. During a class where Product Backlogs and Agile practices are discussed the following question typically arises…

The Question:
What about defects?

The Answer:
Managing defects in Agile is simple. They are merely another desired option (or change) for the product. Add them to the backlog and prioritize accordingly.

I wish I could simply stop there. To be honest that statement sufficiently answers the question, but I always get a funny look or two when I provide that answer to a class or a client so I imagine you would like me to elaborate a bit as well. (I do love to ramble on…)

But what about critical production defects?
Of course there is an exception to any rule, and the idea of handling defect just like any other backlog item is no different. If there is an “oh no, the system is down we simply cannot function” sort of defect of course ‘fire-drill prioritization’ is a valid operating model and you should fix it. Any defect that is causing problems in production and impacting business operations should be addressed with a sense of urgency, we simply ask that you think about the sense of urgency with a critical eye.

Searching “Define: defect” on Google tells us…

de·fect  /ˈdēfekt/
Noun:  A shortcoming, imperfection, or lack: “genetic defects”; “the property is free from defect”.

If we take that definition as is, any request to add a feature to a system is really a defect – right? Clearly the production system has a shortcoming or else we would not be asking for the new feature in the first place. So the question simply becomes… Do you work on a new feature or change the way one already in production is already working?

Additionally, we make compromises as software development professionals all the time conceding to technical limitations, the price of complexity in favor of easier options, and quite often just-get-it-done attitudes. As a result there are lots of things in production that are either not working as intended or could work much better. They are all defects. Many of them were probably coded the way we wrote them down whether or not we really wanted them to work that way in the first place. (Ahhh, the price of traditional requirements documentation.)

So, handling defects in an Agile operating model is really about re-framing the way we think about defects in the first place.

  • A defect is no different than any other option for changing the system
  • Add it to the backlog and prioritize it accordingly
  • Fast-track any critical defects in production that are disrupting business as usual
  • If necessary, use an item type of “defect” when adding it to your backlog

You mean my team has to do all the production support as well?
If you’ve been to one of our Agile Training courses then you’ve likely heard one of the Davisbase crew talk about the best practices of a Agile teams. A key aspect of the curriculum on this is the notion of “start as a team, finish as a team” and it goes along with holding the team accountable for the overall quality of the product. (That’s an opening for another few #BecomingAgile posts right there.)

Ideally, if your organization is taking a ‘product based’ mindset to organizing teams, then yes. If your team is responsible for a defined portion of the product (or the entire product) then your team should pay the price for getting something wrong. The idea of being accountable for the production support of your product is a great motivator for building it right the first time. It is far too easy for a team to get lax about code quality when they know that some other operations team is fixing all the bugs. Now, that doesn’t mean you cannot justify operations teams that are first-level support for business critical the-lights-are-out sort of defects. There is a plethora of strategies for how to break down the assignment of that work.

I’m simply suggesting that if a defect comes up in production, consider the following…

  • Is it critical to have this fixed ASAP?
    • If yes, then stop work in progress – move forward and fix it
    • If no, keep on reading…
  • Can it wait until the next release the Agile team has planned?
    • If no, then consider a fast-track option for getting it done.
    • If yes, then keep on reading…
  • Is it more or less important than something else on that team’s currently defined Release Plan?
    • If yes, then add it to the backlog in correct priority order and update the Release Plan accordingly
    • If no, then simply add it to the backlog and get to it when the time is right

Happy Triaging!


About Leslie J. Morse

Leslie J. Morse serves as an Coach & Trainer for Davisbase Consulting, LLC she joined in the team in February of 2012 and specializes in general Agile practices & principles as well as business analysis and requirements management within Agile projects. Leslie has over 10 years of experience in information technology and digital business strategy. Her diverse experience working in a start-up, small business, Fortune® 500 & Fortune® 50 organizations across a variety of industries partnered with her passion for high quality analysis and process optimization makes her well suited for assisting organizations and individuals with embracing Agile. She is a constant student of the art of software development and has a firm believe that IT systems and solutions are the undercurrent of a business that propels it forward towards success. Leslie’s attention to detail, engaging personality, strategic insight & communication style allow her to work across all levels of an organization building rapport and driving engagement with individual contributors as well as executive leadership.

One thought on “Agile Q&A: What about defects?

  1. Pingback: An Update: Types of User Stories - Davisbase Consulting

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>