In my agile coaching and training journey, I spend a lot of time discussing a wide variety of topics; for example, hardening sprints, refactoring and technical debt, etc. But certain themes form a Top 10 topics list everyone seems interested in. One of those items is how to handle bugs. I get questions like:
These questions surface in my classes and at conferences with amazing frequency. I often smile inside in amazement at the level of interest focused on bugs. But it is an important subject for agile teams, so here are my views toward handling bugs in the above contexts. Now remember, in agile transformations, context counts. Nothing I recommend should be blindly applied everywhere. My only intent is to provide you with some guidance to get you thinking about how to handle your bugs.
Again, it depends. If you size your bug stories as part of your backlog refinement, then yes, they are planned for a sprint and result in velocity. However, there is a potential dilemma. For example, what if you are building a story and find bugs related to your design and coding efforts? As you find those bugs, do you log them and consider them stories? Or are they simply related to the original (parent) story and repairing them is part of the original implementation effort estimate? I’ve encountered quite a few teams who handle in-the-sprint bugs as stories. They estimate them in points and plan them for later. I’ve had many discussions with senior leaders of teams who do this and struggle with their teams’ commitment to work estimation and delivery. Execs feel they’re paying for the story multiple times, at the original estimate and for each subsequent bug story. They’d rather the teams build the story right the first time. There probably is a proximity clause here as well. For example, let’s say a team delivers a story in sprint 3 and later, in sprint 7, they discover two bugs related to the original implementation of the story. What should they do? First, I’d say to fix them in that sprint. You’ve delivered much higher value software in sprint 3 and cleaning it up should be a priority. But what about the points? I’m torn. If the bugs can be repaired quickly, then I’d say do that and don’t worry about the points. If they require significant time, I’d say write a story and estimate/point it. I’d also make it visible/transparent you are cleaning up a previous bug and would allocate space for time to repair.
This is probably the easiest question to answer, but it still has two parts. First, it depends on your Definition of Done (DoD). If it precludes delivering stories with bugs in general or of specific types, then yes, you need to fix them before closing the story. If it doesn’t, then you can deliver and demo it. However, you should probably log the bugs for later. I often see teams make a priority distinction here. That is, in their DoD they’ll indicate fixing P0 – P2 bugs within the sprint and defer others to later. I think the important thing is to have some transparent rules around your handling and consistency across your teams.
Just as talking about bug handling is usually a hot topic in agile circles, everyone may not agree with my advice. It’s the nature of certain topics. Given that, I encourage readers to add comments with your experiences in handling bugs in agile contexts. What have you seen work? What doesn’t work? And importantly, does anyone have something to share about PREVENTION?
Stay Agile my friends! Bob.