We have over 450 bugs. Should I create a separate project just to handle bugs?

TNX Engineering

New JIRA Agile admin/PO here. I am new to the company and have been tasked with setting up Jira Agile - Scrum to manage our projects. Prior to this the company was using a sort of anything goes approach. 

We have over 450 bugs(!) in our system and new bugs are coming in regularly. I like using scrum boards for new feature development, but would like to move the bugs to a Kanban board. The main reason for this is that I'm seeing that new critical bugs are coming in and need to get fixed ASAP. Obviously, I cant have new work coming in and stopping the work the team has committed to finishing during a sprint. 

Should I make a new project just for bugs in order to do this? I feel like it would really help with organization and visibility if I could separate all of these old bugs that have a separate maintenance team working on them into a separate project.

The separation would really help out with helping me keep my focus on the teams that are building out new features. As a former BA who was just recently moved to a new PO position, I still work writing requirements and developing new features. 

I wish we could stop all new development to focus the whole team on fixing all the bugs, but unfortunately that cant happen due to various legally required new features that we have to add for our customers. 

Nic Brough -Adaptavist-

It might be a good thing to do, but it might not.  JIRA will support you either way (I know of projects with tens of thousands of bugs, and it's the right way to do it.  For them).  This really is a procedural and organisational question, and the real answer is "do what works best for your users"

To try to help though, there's a few things I'd consider.

First, the boards.  It will probably help to stop thinking of boards as the defining factor.  They are a brilliant way to visualise and work with your issues, but they are actually views of your issues, not the containers for them.  Projects are the containers, and boards can select from many projects.

Scrum boards allow you a lot of planning features, and it sounds like these are working well for you as they are.  Kanban boards however, are a lot "lighter".  I frequently recommend that people use Scrum boards as a full-on planning tool and they should use one single board per team or product or purpose (because trying to plan with many scrum boards looking at the same thing is hard).  But then go ahead and create lots of Kanban boards looking at the same lists.  As long as your users don't use "release", Kanban boards are often a really good, simple way to look at a list of stuff that needs doing.

Second, your process and organisation.  To me, it does sound like you probably need a decent separation between "new bugs" and "planned new work".  You could do this by having scrum boards that say "all issue types except bug" and Kanbans that say "only show us bugs", but I suspect your instinct to separate bugs out into their own project probably is going to be easier for you (As well as meaning you can have really simple boards that just look at "whole project").  If you do decide to have "bugs" and "planned dev" as projects, I'd suggest allowing your developers in the "bugs" project have the ability to move issues into the "planned dev" project, to cover the cases where a user raises a bug that turns out to need full planning like a new feature.  The downside of this approach is that things like versions and components are separated out by project, and you'll need to do some extra management on releasing your improvements.