In my agile coaching and training journey, I spend a lot of time discussing a wide variety of topics. But there are themes that form a “Top 10” of topics that everyone seems to be interested in.

One of those items is how to handle bugs. Questions like:

• Do you estimate bugs (planning poker – points)?
• Are bugs equivalent to stories?
• When do you “file a bug” while sprinting?
• Do you count bugs as part of your velocity?
• Can you deliver a story in a sprint with bugs still open?

come to the surface in my classes and at conferences with amazing frequency. I often smile inside in amazement at the level of interest focused towards “bugs”. But that being said, it is an important subject for agile teams and I thought I’d discuss my views towards handling bugs in the above contexts.

Now remember. In agile transformations, context counts. So nothing I recommend should be blindly applied everywhere. My intent is to instead provide you some guidance to get you thinking about how to handle your bugs.

Do you estimate bugs (planning poker – points)?

In this case I’m talking about doing planning poker and estimating (applying points) to bugs. I’ve thought for years that you probably don’t want to estimate more common bugs. That it can be quite wasteful. That is, by the time you estimate a fix you might as well actually fix the bug. But in backlog refinement, we tease apart estimation vs. repair time. So often you spend nearly as much time estimating the bug as you would spend fixing it in a later sprint.

I’d much prefer not estimating most bugs, but focusing effort towards investigation and then immediate repair. However, I do see two situations where it makes sense to estimate bugs.

First, it probably makes sense to estimate the “hard ones” or those that are fairly complex or those the cross-cut major areas of your systems. In my experience, one category of these is performance bugs. They typically take lots of effort and time to resolve. I could easily see running planning poker to explore the nuance (and size) of these bugs.

Second, I often recommend “packaging” bugs into themes. So not estimating individual bugs, but theme-based packaged into a user story that might represent 5-10-20 individual bugs. In this case, they might be all UI bugs related to a specific workflow within an application. That way the total starts “weighing in” as a typical or average user story and the effort to estimate makes more sense.

Are bugs equivalent to stories?

I remember a client a long time ago who was using Jira to track their defects prior to “going Agile”. When they made the move, they obviously selected Jira as their agile ALM tool. And this created a clear path for their 5000+ historical bugs to suddenly become “stories” in Jira.

These were then augmented by “real” functional stories, so the product backlogs became huge. What they learned is that bugs really aren’t’ equivalent to stories in size or in attention, as I mentioned above. Furthermore, they realized that the large number of bugs diluted the focus for and attention to the backlog.

In other words, I don’t think all bugs should wind up being stories. Perhaps 20% of the largest and most complex should, but the remainder (small, cosmetic, historical, trivial, straight-forward) should not be.  Again, aggregating them is a more effective strategy.

When do you “file a bug” while sprinting?

Never. You try to build software without bugs, and if you find them, you fix them immediately 😉

But if this isn’t your reality, then perhaps it’s a fair question.

If you’ve ever taken one of my classes where I discuss Definition of Done, you know that one of my favorite constraints for agile teams is no bugs per story. That is, if the team has created 15 defects during construction of a story, I’d expect all 15 to be resolved before gaining “credit” for the story. Independent of the priority of the bugs.

Now I’ve been accused of being harsh with that constraint, but it does influence keeping your code base clean.

So what if a bug does slip out of the sprint? Or what if you find a legacy code bug during sprint work? Well, I think you file it. So consider the sprint boundary as the filing point. Try to focus on collaboration and repair during the sprint and if any bug cascades beyond the sprint, the normal action is to file it.

Do you count bugs as part of your velocity?

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. I’ll explain it via an example.  What if you are building a story and then 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 the bugs is part of the original implementation effort estimate?

I’ve encountered quite a few teams who handle these story-delivery, in-the-sprint bugs as stories. They estimate them in points and then plan them for later.

I’ve actually had quite a few discussions with senior leaders of teams who are doing this and they really struggle with the team’s commitment to work estimation and delivery. The execs feel like they’re paying for the story multiple times, at the original estimate and then for each subsequent bug story. They’d rather the team build the story “right” the first time.

Now there probably is a “proximity clause” here as well. Here’s another example. Let’s say a team delivers a story in sprint #3 and then later, in sprint #7, they discover two bugs related to the original implementation of the story. What should they do?

First, I’d say – 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 the bugs require significant time, then I’d say write a story and estimate/point it. I’d make it visible / transparent that this is cleaning up a previous bug. But I’d allocate space for the time to repair.

Can you deliver a story in a sprint with bugs still open?

This is probably the easiest question to try and answer, but it still has two parts.

First, it really depends on your Definition of Done or DoD. If it precludes delivering stories with bugs in general or of specific types, then yes, you need to fix the bugs before closing the story. If it doesn’t, then sure 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 then consistency across your teams.

Wrapping Up

Just like talking about handling bugs is usually a hot topic in agile circles, I’m sure not everyone will agree with my advice. It’s just the nature of certain topics.

Given that, I’d encourage readers to add comments with your experiences in handling bugs in agile contexts. What have you seen work? And what doesn’t work?

And importantly, does anyone have something to share about PREVENTION?

Stay agile and bug free my friends,

Bob.