Handling New Issues in the backlog

Question

We are a small team mostly focused on medium to large scale websites. I am going to merge all issues for all of our projects into one backlog using Kanban with JIRA. The idea being that no one gets to pick and choose what they want to work on, but rather we can prioritize everything that the company needs to do and everyone will work on their next ticket in the que.

This will lead to hundreds of tasks in my backlog. I'm fine with this when it comes initially importing all the tasks for a project and prioritizing everything. However my quandary is as new issues are created by the team (through testing or just new things that come up) and go into my backlog what is the most efficient way for me to handle these without loosing track of what items I need to prioritize? Do I prioritize those right away? daily prioritize new items? have them go to some pre-qualified status to help me easily see what are new issues that need be entered into the backlog? or some other method that someone far wiser than I has already developed? thanks for any help.

Backstory if it's helpful: We are a team of 8. In the past we have had a serious issues with handling projects separately as well as new projects separated from ongoing support for current clients. Obviously there has been zero true project management. Thus leading to the person who is responsible for ongoing clients to yell about their tickets be priority and likewise for the person trying to coordinate our new projects to scream that developers should be working on those first. Thankfully we are fixing that. Since I've been the most vocal about it, I get to play PM. I don't want to just play PM though. I'm doing my best to study many methods, read on here, and learn from others. I've chosen Kanban because I think it helps keep the flow going (there's always a flow of issues in our team), easily see what's the priority across the company, handles efficiency and resources with WIP limits, and makes sure that everyone knows what is the next thing they should be working on.

Answer 1

[...] what is the most efficient way for me to handle these without loosing track of what items I need to prioritize?

You can manage this with JIRA's JQL quick-filters. The simplest solution would be to have, say, a filter that shows everything in the backlog that was created in the past week:

created > -7d AND status = Backlog

And then go through them once a week to prioritize them.

You can make a more complex system if you require additional rigor (managing things by status or project, etc.), but for the beginning I would suggest you start simple.

Answer 2

First of all you don't usually want tasks in your backlog but ideas that deliver value. The tasks are usually represented by the columns in the Kanban system, but if it is more of a task board then read on.

I don't know if it is appropriate for you, but when I hear 100s of tasks in the backlog I wonder if you expect them to be more or less valuable than the new ideas that come from the team? Usually once we get started our idea of what needs to be done changes so I would expect many of these tasks to become obsolete. If the existing ideas are more valuable than those coming from the team, then I would suggest getting them done first, or at least until the product starts to take shape. Then just ditch the rest and allow the team to recreate the useful ones. If the team ones are more valuable, then only leave the core minimal ones in the backlog and ditch the rest.

If you don't want to lose all the ideas now, you could cluster them to identify some epics and have those in your backlog instead of the detailed ideas. Perhaps one of the early columns after the backlog could be to flesh out the selected idea.

Another option could be to use some sort of voting tool like Tricider to allow everyone to add new ideas and vote on the existing ones. You could have a WIP limited "Input Queue" that is replenished by the highest scoring idea.

Answer 3

When you say issues, do you mean the Jira issue type or a real issue with your products (a bug)?

If you meant the issue type, I'd definitely separate them in different swimlanes. I'd put customer bugs at the top, then put internal bugs, then features at the bottom. This should be a signal to the team that they first need to tackle customer and internal bugs and only then go to new features. If you want to know more about this approach, read on here: Kanban for Software Development

If you meant bugs, I'd rather start figuring out why my team has piled up hundreds of issues. When you have that many bugs for a team of 8, this might be a manifestation of corrupt practices and/or behavior, where Kanban is not likely to help a lot.

I hope I didn't misinterpret the question.