Strategies for Dealing with Bugs During Sprint
It is the intended result of the complete process of presentation of textual material in order to communicate meaning.
About the Author
Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer.
Kiryl Baranoshnik is an experienced Agile and Lean practitioner. He works as an Agile Coach at a large bank in the Netherlands and shares his knowledge publicly as an Agile trainer.
Here's another surprisingly popular topic that confuses a lot of people. What should you do when you find a bug during an iteration. Should you work on it immediately or should you put it off for later? Do you have to track it on your task board or is it not worth the time? The answer is actually not that complicated. Let's take a look.
There are essentially only three ways to handle a newly discovered bug:
- fix it now,
- fix it later,
- ignore it.
Read a related article about unplanned work during sprint:
Strategies for Handling Unplanned Work During Sprint
Fix It Now
What to do. Fix it immediately as a part of the current sprint.
When to apply. The strategy proves to be sensible in either of two cases: when the bug is quick to fix — and then it's easier and cheaper to fix it immediately; or when it's critical — and then you don't really have another choice.
How to track. There's a lot of questions specifically about how to track non-production bugs that have been found during active development of a user story. You can track it in many different ways and the easiest one is, of course, not to track it at all. It works best for small bugs that can be fixed within a short amount of time, typically, a couple of hours and allows you to avoid unnecessary bureaucracy.
That's not always the best option, though. In the majority of cases you still want to visualize it because it's blocking the user story and you want to see blockers on your board. There are a couple of options how you can do it.
On a physical board the typical approach is to put a red sticky note over the card in progress. It can be a bigger piece of paper with additional information on it or just a small red sticker. If you want the bug to be accounted for against your WIP limits (provided you have them) than you may want to put a separate card on the board in addition to the red sticker. It will occupy additional space on the board and will be counted towards the limit in the respective column thus incentivizing the team to fix the bug.
When to apply. The strategy proves to be sensible in either of two cases: when the bug is quick to fix — and then it's easier and cheaper to fix it immediately; or when it's critical — and then you don't really have another choice.
How to track. There's a lot of questions specifically about how to track non-production bugs that have been found during active development of a user story. You can track it in many different ways and the easiest one is, of course, not to track it at all. It works best for small bugs that can be fixed within a short amount of time, typically, a couple of hours and allows you to avoid unnecessary bureaucracy.
That's not always the best option, though. In the majority of cases you still want to visualize it because it's blocking the user story and you want to see blockers on your board. There are a couple of options how you can do it.
On a physical board the typical approach is to put a red sticky note over the card in progress. It can be a bigger piece of paper with additional information on it or just a small red sticker. If you want the bug to be accounted for against your WIP limits (provided you have them) than you may want to put a separate card on the board in addition to the red sticker. It will occupy additional space on the board and will be counted towards the limit in the respective column thus incentivizing the team to fix the bug.
A team has flagged the bugged user story with a red sticker and created a separate item for the bug itself. Notice how this bug consumes the WIP limit for the "In Progress" column.
If your tracking tool is digital, your options depend a lot on the software you use. Let's take Jira as an example. What I've found to work the best is having a special issue type called Sub-bug (the name doesn't really matter here) which is just another version of a Sub-tasks. It's also a good idea to flag the story for even more salient visualization — that's the analogue of a red sticker on a physical board. Creating a first-class bug entity is still possible, of course, with the same premise as in the physical board example above.
A team has created a sub-bug and flagged the parent backlog item.
Fix It Later
What to do. Create a new backlog item and put it in the product backlog. After that the bug is planned for future iterations just like any other backlog item.
When to apply. Sometimes, while still being critical, the bug might not be critical enough for you to fix it right away. Especially if it seems to be too large. This applies both to bugs found in production and to bugs that have been found during active development of a story.
How to track. Create a new card and put it in the backlog. If you have specific types of cards for bugs (usually you do), use them. On a physical board it's typical to have red sticky notes for bugs, in tools like Jira by default there's a specific entity type called Bug or Defect.
When to apply. Sometimes, while still being critical, the bug might not be critical enough for you to fix it right away. Especially if it seems to be too large. This applies both to bugs found in production and to bugs that have been found during active development of a story.
How to track. Create a new card and put it in the backlog. If you have specific types of cards for bugs (usually you do), use them. On a physical board it's typical to have red sticky notes for bugs, in tools like Jira by default there's a specific entity type called Bug or Defect.
A team has created a new bug in the backlog.
Ignore It
What to do. Do, well… nothing.
When to apply. On some rare occasions, it's not worth it to bother about the bug in the first place. This may happen when the bug seems to be relatively hard to fix while the impact of not fixing is minuscule. You accept the risk with the notion that if it's really important, the bug will be reported again at some point.
How to track. You don't track it. If you've already been working on the bug for a while and have a card for it, simply remove the card from the board.
When to apply. On some rare occasions, it's not worth it to bother about the bug in the first place. This may happen when the bug seems to be relatively hard to fix while the impact of not fixing is minuscule. You accept the risk with the notion that if it's really important, the bug will be reported again at some point.
How to track. You don't track it. If you've already been working on the bug for a while and have a card for it, simply remove the card from the board.
Production and Non-production Bugs
At first glance, production and non-production bugs seem different. But if you think about it, the difference is not that huge. If the bug small or extremely critical, you're better off fixing it on the spot regardless of when you've caught it. If it's too big to fix it now, you put it on the backlog, again, regardless of the timing. In other cases you simply don't spend time on it. The only difference is in how you decide how critical it is. In case of production bugs you will be leaning much more towards fixing it later because they tend to be bigger in size and require more work. For non-production bugs in the majority of cases it makes more sense to fix it now while the context is still fresh.