Two ways to approach kanban bug tracking

Many people often ask the question, “How should I deal with bug reporting when I’m managing issues on my team’s kanban board?”

For example, is it best to report bugs on the fly (pun intended) and have them drop into your current sprint’s board?

Or, is it better to just have a totally separate board specifically for bug tracking?

In this post, we’ll examine two different ways you can manage your bug tracking flow. These two ways are often dependent on some of the following factors, so keep these in mind as you’re reading on:

• How many people are on my team?
  • Related: How many people are in each specific role? In other words, how many developers are working on the project? How many QA team members do we have? Do we have a product owner? Am I the product owner? How did I get into this role?
• What are you working on?
  • Are you developing a full-fledged eCommerce site for a client that has a long deadline? Or are you building a web app that has minimal features that you’ll continue to develop as you get more user feedback? A longer, client-driven project might require a different approach, especially if the client is hands-on. On the other side, a smaller, focused web app might dictate a quicker kanban management style, especially if you’re looking to build it in a shorter amount of time.
• Am I using a sprint system? Or are we tackling things in a looser kanban style?
  • FYI: There is no right or wrong answer here. As an example, a smaller team might consist of a developer and a product owner, and these two teammates might have a broad skillset. Their deadlines might be shorter, so using a kanban board to manage issues on the fly might be more appealing than setting up a huge roadmap with lots of complexity.

What is kanban?

As a refresher (and for those looking to learn), kanban is a lean method to manage and improve work across human systems. Most people practice the kanban system using a kanban board, so that’s probably where you’ve encountered kanban at some point in your career. Or, maybe you saw this famous scene from HBO’s “Silicon Valley”, where the characters implement a “scrum” system unknowingly and compete to complete tasks more quickly to prove their competence.

You don’t have to use a kanban board to compete, though, especially when it comes to bug reporting and tracking. The main thing is that you:

• Report the bugs, which go into a backlog.
• Select the bugs to be fixed, which then go into “in progress“.
• Completed bugs that then go in review to make sure they’ve been fixed properly.
• Finally, completed bugs go into a completed column on the board.

Issues, tasks, or stories — they’re all basically the same thing — can be organized into epics, which are basically just groups of tasks.

For instance, say you’re hosting a birthday party and you’ve got three big things you want to accomplish: 1) You’ve got to invite 10 guests, 2) You’ve got to make the cake, and 3) You’ve got to decorate three rooms. Epic #1 would be called “Invite guests”, and each task could be a person that you’ve going to invite (since this is 1993 and you need to call each one individually). Epic #2 can be called “Make cake”, and each task can be part of getting the cake together, such as “Buy ingredients”, “Actually bake the cake”, “Cover in frosting”, etc. Finally, Epic #3 can be called decorate, and the three example tasks could be “Decorate hallway”, “Decorate living room” and “Decorate dining room.” As you progress with each task, you’ll move it from the backlog, to “in progress”, to review (more on this below) and then finally, “Completed”.

Now, using the same example with bug reporting, say your partner is also hosting the party with you and they’ve agreed to call you out on all the mistakes you’re making while working hard putting this party together (in other words, they’re bug reporting on your project). When decorating, you put up one of the banners, but it fell down while you were selecting a different issue for development. Your partner would then add a “bug” to the tracking in Epic #3 of “Rehang banner in living room.” You’d then work through all the thousands of bugs your partner reports on your party, and you’ll eventually wonder why you offered to do this in the first place (similar to your software development job).

The cool thing about kanban is it isn’t limited to just software development (take our party example from above); we’ve used kanban boards in marketing, advertising and people management.

Kanban is especially effective when you’re working on a remote team.

The main thing is just getting everyone on the same page, and this is especially helpful when you’re bug tracking with your QA team.

Integrating bug tracking into your current kanban board

Depending on the size and length of time you have for your project, you might just opt to report bugs directly into your current kanban board. For example, using our party analogy from above, if you’re planning a party for this weekend and you’ve only got maybe a few epics that you’re working on, you might just have your team report those bugs directly into your backlog so the developers (or you as the party planner) can take each bug and fix it within the same workflow.

This method is helpful for when you have a limited team, or want to keep everything visible in the same place.

This method is also especially helpful for projects that are mostly in maintenance-mode. Say, for instance, your business has decided they’re not going to redesign their eCommerce site for two years, so you just need to make sure you maintain and improve the performance of the site over the next two years. You could have your team report bugs onto the current kanban board that you’re using, and the developers could select each one that’s reported and move it as they have the time.

At BugCatcher, we use this method since we have a limited development team (Jon) and a QA specialist who is out of control (Justin). Justin reports items to the backlog from an awful product manager’s standpoint, and Jon selects which bugs he has the capacity to take on (and can also evaluate the level of effort needed to fix those bugs).

Creating a separate board for bug tracking only

This method is more helpful when you’re working on a project with many different user stories, epics, team members and/or a long deadline/series of sprints (or series of deadlines). It’s useful when the reported bugs might get lost in the shuffle of all those different items.

As an example, say your team is composed of 20 people and you’ve got 20 issues in each of 20 epics. That’s a LOT of moving pieces and people. When your QA team starts checking the work, it might be best for them to report all these bugs into a separate kanban board with the same epics as the working kanban board so that team members can go into the bug board and work on each of the bugs.

That’s especially helpful if you have team members dedicated specifically to fixing bugs. Some team members may be specifically dedicated to building the features in each epic, and some might come in just to support and fix bugs on the fly, moving your project along well.

Some tools (like Jira) even let you move issues between boards, so if for some reason a bug ends up being a feature (kidding kinda), you can transfer that issue over to the other board without losing the data attached to it.

Use the system that works best for your team

At the end of the day, the #1 thing you really need to worry about is: what is working best for my team?

If keeping the user stories and bugs all in the same place is the way your team agrees will work best, than that’s the way to go.

But, if keeping all the bugs separate keeps things more organized, then that’s definitely the approach you should take.

Kanban was designed to help, not hinder, the development process, so make sure whatever system you choose is the one that makes your bug-squashing highly efficient!

How are you using kanban boards with your team? Tweet us at @bugcatcher.io!