Create multiple backlogs within one Jira Agile project

Yen Pham October 3, 2014

Within the plan tab, we'd like to have the following lists

  • Current sprint (already exists)
  • Backlog (already exists)
  • Unprioritized (doesn't exist, would include untriaged bugs, features, stories, etc. that aren't ready for development)

I know I can create quick filters that would show any combination of issues, but we'd prefer to easily drag issues between two backlog-type lists; this is versus opening the untriaged issue in a separate window and changing it's state to "Ready for Development" to make it show up in a filtered backlog 

Thanks!

 

7 answers

8 votes
Thom Franklin June 21, 2018

I apologize if I have misread the issue.  

We have a simple fix.  Just make an inactive sprint called backlog 2 or whatever else you want to call it.  

That way you can collapse or expand it like sprints, and you can send from the actual backlog to it.  

vampyren June 22, 2018

No problem and thanks for the tips. This would be an option if we were using Scurm. Right now we use Kanban sadly. Is there a way you can think of with Kanban?

Nikola Nikolov April 17, 2019

Just the thing I needed - thanks Thom!

7 votes
Boris Barcelli November 13, 2017

Hi Yen,

Sharing your pain. When we were using TFS, we used to have one technical debt backlog and one product backlog. The PO would prioritize the product backlog, and the team and I (SM) would prioritize the technical debt backlog. Then come the sprint planning, we will fill 20% of the capacity with technical debt items and the rest with product development. Now with Jira I can't, tks Jira.

BTW, for the people telling us we are doing it wrong, there is a special place in hell for the SCRUM police.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
November 13, 2017

You're doing it wrong....  Nah, you're not in the slightest. 

Jira doesn't support this directly because it's not generally done with "multiple backlogs" (they're confusing and messy).  The "take x% technical debt in each sprint" is a great thing to do, and I wish more people did it.

The usual approach is to have a clear indicator of type - if an issue is classed as product or technical debt by using the issue type(s) or Epics or labels, you can see this in the backlog, so when you are dragging things into the sprint, and pull in what's needed.

The weaknesses there are twofold

First - prioritising single backlogs is a pain.  It's very easy to end up with the top n issues all being product or tech debt, so it's hard to re-prioritise the others up to include in the sprint. 

To help with that, I try to use quick-filters and a slight kludge.  One filter is for "product" and another for "tech debt".  You prioritise within each, ignoring the other.  The slight kludge that comes in is you have one issue that's always open, and is both product and tech debt.  When you've finished prioritising each pile, you move a handful of the top issues (ideally slightly more than the amount you'd like to get done in the next sprint) above the marker.  Then you can do sprint planning, drawing in  as much as you can from both sets of issues that are above the marker.

Second - this is the one I've not got any real fix for.  The method does not help you with sizing a lot, you have to rely on your prioritising users to get the numbers about right.

I know this doesn't seem better than "two backlogs", but it seems to work.  I stole it completely from a place that actually has five sets of inputs from users (and sadly, no tech debt, it would have been fantastic to have added that as a sixth!).

Having scribbled all of that, there are other methods.  Having three boards can do it (a main one, one for tech debt, third for product - a little clumsy because you never sprint on anything other than main which looks odd).  And another option is to implement the incoming queues as status.  A workflow would start with "open" or "new", and that would transition to either "tech debt" or "product", and your backlog is "anything in those two status", but I don't feel that really solves a lot.

Like # people like this
Boris Barcelli November 19, 2017

Thanks Nic for your comprehensive answer. For now I have resolved my problem by creating a separate project with my tech backlog in it. Then on my product backlog I created a board based on a filter that merges both projects. If it doesn't work as well as I expect, I will try one of your options.

4 votes
vampyren April 21, 2018

I'm finding myself in the same situation, I want basically 2 section in the backlog. One for regular backlog and another for on-hold/archived items. We want to be able to pick the items from this list back to Backlog with ease.

From what i can see this should be a simple thing to do for Atlassian. I have created a Status called: On-Hold. Today there are a simple Column mechanism where you drag your status into that. Why not do the same thing with backlog?

Make it like column and let users drag the Status they want in Backlog.

Anyway if anyone has found a work-around they think it good for now please do share.

Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 21, 2018

Options:

  1. Exclude “on hold”, I.e. leave it unmapped. Then have a dedicated board for “onhold” and map it into the “backlog”. When ready change the status to “Backlog” or what ever status you use for Backlog on the main board.
  2. display status on cards in Backlog. Keep all “On Hold” at the bottom.
  3. place all on hold issues into an on hold epic keep all issues with that epic at the bottom and or select all epics except that on displayed.
  4. dont include on hold status in the main board filter. Use a filter or board to move issues from onhold to backlog

etc.

Like Shailesh Patel likes this
vampyren April 21, 2018

Thanks allot @Jack Brickey, good options. I will try and see which will work best.

Currently i have made several boards in my 1 project for various purposes and use component to separate these boards from each other. Not the best use of components but my users are just learning Jira and they get confused with even the name epic, story. Best would be to have separate projects but to them it was much simpler to switch board than projects so we went this route.

Also we only use Task and subtask since it makes more sense to them. I will see how i can use your recommendations in relation to how we use the boards.

Cheers!

3 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 3, 2014

Not really.  The way Agile generally works is "backlog", "in sprint and in progress", "in sprint and done", and "stuff we did in ended sprints".  Two backlogs doesn't make a lot of sense, especially as the whole point of planning is that you have a single backlog to prioritise and work on.

I suspect this is a (large) feature request that Atlassian will probably say "no" to.  But you could at least ask - raise it at https://jira.atlassian.com/browse/GHS

Yen Pham October 3, 2014

It was meant to ensure that the backlog remains clean and separate from untriaged feature requests / bugs which can grow fast and remain pretty big. I'll try raising a feature request though thanks

Like # people like this
Paul Leonard January 18, 2017

Can't agree with you more Yen.. while some purist may consider that only one backlog is necessary for any given project, I feel this creates limited planning  that can jeopardize development. When some projects reach a certain size, and span more than a year of development, like many of ours, multiple backlogs ARE necessary. i.e. an 'immediate' backlog to supply current and pending Sprints within a given phase of development, with another backlog for cards to be considered in the future, or past a certain stage, such as pre-deployment, and post-launch phases. Just saying based on our experiences over the past few years...

Like # people like this
Rameshkumar R January 5, 2018

I agree with YEN , we do see a need for multiple backlogs.

In ASIL Sw development , we would like to have one major Change request which flows between multiple backlogs say for example . Now the change request has cleared the design phase it should moved to development backlog 

 

If we have all in one place it will be more confusing .  I really see a usecase scenario to have multiple backlogs and then have different boards based on it 

Like Luke_Capizano likes this
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 5, 2018

You're 4 years out of date, and please see the comment further down on Boris's answer.

Ram Krishna Pratap Singh November 27, 2018

I completely agree with @Paul Leonard, People start telling Agile says X so we will strictly follows X, which is not the case. Agile is adaptive process and we should have flexibility to map with what project really throw to us. One of the other tool which we use along with Agile allows to create Release and Product backlog. Release backlog makes planning much easier since we can agree 2 sprint worth of work and it is very easy to track the KPIs of the team. We pick the items from Release Backlog and product backlog is funnelled through Defect and production issues backlog.

Like # people like this
Dan Shinton June 24, 2019

I know this is an old issue but consider this. We want multiple backlogs because we get requirements from multiple sources. We get requirements from our Business Analysts, Sales Department, and from the Development and Operations Teams. It would be great if they all can manage their own lists of features they want, sorted by priority, so at the sprint planning meeting, we can ensure all the stakeholders are being heard as to what their most desired features are.

Like # people like this
Jack Brickey
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 24, 2019

@Dan Shinton , it may not be the method you want but you could do this today I think.

Consider creating multiple kanban boards. example:

  • create a "ready for dev" (RFD) status. Each requirement team would manage their requests and move them into RFD status
  • create a dev board that excluded issues in the To Do status (not yet RFD). RFD items would show in the dev backlog
  • create kanban boards for each requirements team
  • use Components to reflect the various requirements teams

there are other creative ways to manage too, e.g. labels

Like Luke_Capizano likes this
1 vote
Johnathan_Browall_Nordström February 13, 2020

Hi

When using the agile framework SAFe you have multiple backlogs. One Program backlog, and then one team backlog as well. So I wish that JIRA would implement this feature

Shailesh Patel May 5, 2021

Johnathon - the SAFe program backlog is Kanban.  So I create a Kanban board for program level features.  We have an issue type called Features. We then decompose (or map) stories to a feature using Jira linking.  A Team level Scrum board manages the stories.  That is the gist of how we have implemented SAFe structures. 

1 vote
sanjay sahuu March 18, 2016

Hi Yen,

 

Did you get any solution, we too are looking for having multiple backlogs, and you are right, one backlog remains clean and other would be Unprioritized which are still evaluated.

Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 19, 2016

The situation hasn't changed, because it's still the wrong way to think of it.

Luke_Capizano September 19, 2019

There is no right and wrong when it comes to how a team works on their products.

Like # people like this
0 votes
Jobin Kuruvilla [Adaptavist]
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 5, 2014

May be use 2 different boards for the same project? One for triage and another for the sprint planning?

Yen Pham October 6, 2014

I'm aware of such an option and have implemented a few times. What we really want is to have a separate section for triage similar to how there's a separate section for each sprint. I have also tried using "Create Sprint" as a section, but sprints have to be executed in the order you create them, so that didn't work.

Adi Furca October 2, 2020

@Yen Pham , you can now move sprints up or down :D
Screenshot 2020-10-02 at 16.01.28.png

Like Shailesh Patel likes this

Suggest an answer

Log in or Sign up to answer