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- · Accepted solution]

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.

[TNX Engineering]

Great answer. This is great advice and really helped. Knowing that boards are views of my issues and not containers puts things in a clearer light. I am leaning toward your advice to have a board for each team/product, that solves the difficulty keeping track of things in a sea of issues problem without confusing everyone as to why we have separate projects. If I go this route, am I correct to assume that each board will have its own backlog that can be prioritized separately from the other backlogs on the other boards? Would you mind clarifying this statement? "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 far as this goes: "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." What does extra management entail? I am guessing that you mean to say that I would have to move the bug issue back to the the original project before releasing them. Thanks once again for your advice

[Nic Brough -Adaptavist-]

If you have scrum boards for each team/product, then yes, they'll have different backlogs. But you do need to be a little careful about scrum boards that may overlap. As a worked example: Imagine you have three projects - AAA, BBB and CCC. If you create one scrum board per project, you're fine. If you create a scrum board for a team that covers project AAA and BBB, and a second for just CCC, you're fine. But you may run into procedural clashes if you have a board covering AAA and BBB, and a second board with BBB and CCC. You'll see sprints from all the boards because BBB issues could be being worked on on either board. AAA and CCC will be ok, it's just you may find the crossovers in BBB mess up your planning process. Until you're comfortable with the idea of how it's going to work, I would try to avoid that scenario, and avoid including sets of issues on multiple scrum boards. Kanban boards on the other hand - don't care, they don't have planning and sprints. So you can happily create several of them for different reasons and they'll be fine. They will work on the same issues, but they will not affect your sprint setup directly. Now, on to the versions and components. Those are *project* artefacts. If you have version 42 in project AAA, it won't appear in BBB or CCC. Even if you add "version 42" to BBB or CCC, they are still separate versions (different IDs in the database). So if you have distinct versions of software to release, you may want to consider keeping your issues in the same project. Then use a scrum board for all your planning, and Kanban boards with filters like "project =aaa and issuetype = bug" and "project = aaa and issuetype != bug" to view the subsets of development work.

[TNX Engineering]

Thanks so much!