Within the plan tab, we'd like to have the following lists
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
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.
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.
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.
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
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...
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
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.
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot