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.

3 Answers 3


[...] 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.

  • thanks. this is where I was planning to start and am thankful that someone says it's ok to start simple rather than jumping into some big setup. Just wasn't sure if there were any known strategies for handling this scenario. Trying to learn from those who have gone before me rather than reinventing the wheel. I'm glad I found PM stack exchange Commented Feb 14, 2017 at 13:39
  • I chose this as the answer because really we just need to start simple and not over think it in the beginning. Commented Feb 17, 2017 at 2:53

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.

  • Thanks for the feedback. For me, the backlog was going to basically be my staging area if you will so on the actual team Kanban board To-Do (the fist column) didn't look like a monster to the team. I was would just move from backlog to To-Do in batches as the the To-do column dwindled down. The idea is that in a website we have known tasks for each project. If I have those from the beginning and keep them in there, then we can see estimates of upcoming milestones based on resources and all tickets in the system. Should I be approaching this differently? Commented Feb 13, 2017 at 14:31

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.

  • Thanks for the link! Yes, I mean JIRA issue types (task, features, bugs,etc). To setup the project I plan on planning out all the tasks that we know need to be done on the project (i.e. we know we will need to design templates, create wireframes, setup the dev and production servers, etc). Along with estimated padding at the end of the list, this will give us a real rough estimate of completion when we mix in with our projects' issues the team is working on. So once this initial backlog of stuff to do is created, looking for the best method to organize when someone does submit a new issue. Commented Feb 14, 2017 at 21:42
  • Ran out of characters above.. I think in the end I may just be over thinking it. If I just take some time every other day or as often as needed based on workload to prioritize new tickets, I think it'll be a good start. Commented Feb 14, 2017 at 21:44
  • I definitely agree with you. Start small and start where you are. Then "Improve collaboratively and evolve experimentally". This is one of the core Kanban practices, right :)
    – Mita Ka
    Commented Feb 15, 2017 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.