Avoid bloated backlogs and The Sea of Mold — a scalable Jira setup for managing your Product and Teams projects effectively

👉 Disclaimer #1: This piece is a bit lengthy as it covers both the concept and an implementation guide. However, if you struggle with maintaining a huge backlog for your product and your teams — I guarantee it’s worth reading.

When I started working as a scrum master in 2015, I was paired with a product owner with a great sense of humor. He managed a backlog with HUNDREDS of legacy ideas.

Naturally, it was impossible to actually work with such a huge list, so his solution was to only care about the top 30 stories, and the rest of them were drowned in “The Sea of Mold” beneath, as he called the bottom of his backlog.

A few years later, after launching my own product, I found myself in a similar situation — managing hundreds of bugs, old ideas, new ideas, maintenance tasks etc.

Initially, I was doomed to replicate what I already knew — creating all-purpose projects for collecting new issues, prioritizing current work, and managing all reported bugs, ideas, and requests.

But this time I was actually responsible for the outcomes, and at some point, the workflow became such a drag, I had to rethink it from the ground up.

I diagnosed a few major problems:

• We had too many tickets, so it became cumbersome to order them and impossible to remember what’s actually written down and what’s not.
• On one hand, we needed separate projects for Design and Engineering, since some of their tasks were not overlapping, but on the other hand, most of their work was focused on the same issues related to our product. It was notoriously difficult to establish where we should keep our requirements and as a result they were usually scattered.
• Since we mixed technical and business language, it was impossible for our stakeholders to understand and verify if a scope of an issue matches their expectations.
• For me personally, it was really difficult to plan our work in the mid-term, i.e. several sprints ahead.

I started mapping the real-life process my setup needed to support, and that’s how I came up with a solution that is scalable, and I’ve been using it with success for almost 3 years now. Since then, I never found myself dealing with The Sea of Mold; I always knew where to place incoming requests, and I am 100% certain I didn’t overlook any of them.

If the above seems like the opposite of what you deal with right now — follow me and learn how to manage a product in Jira and drown in issues.

👉 Disclaimer #2: In 2022, Atlassian launched a new product called Jira Product Discovery. It’s optimized for collecting and prioritizing ideas. While it’s a great tool, it’s not included in all pricing plans. I’d argue that the presented solution is a good-enough substitute for Jira Product Discovery for mid-sized teams and products.

The process

Before we jump into learning how to set up Jira, let’s look at the process we’re dealing with, regardless of the tool itself.

The whole software product’s backlog management process can be divided into 5 major phases:

1. Collect — capture ideas, requests, bug reports (your own and from other people),
2. Triage — read, understand, and sort the collected tasks based on urgency and impact into some predefined and well-organized lists,
3. Plan — strategically pick issues from the predefined boxes and map them to future timeframes,
4. Refine — write down requirements and agree on the final scope and implementation plan,
5. Execute — pick a small portion of tasks from the top and commit to delivering them during a sprint.

Of course, there are a lot of other processes going on in parallel — data analysis supports the Triage phase, your roadmap impacts the Plan phase, and incidents can disrupt the Execute phase. However, these are not that important to the core flow of issues.

Now, let’s look at some more specific requirements for these phases.

Collect

• Other people need an easy process for reporting their ideas, bugs, and requests. The easier it is, the more probable it’ll stick.
• The better the initial description of an issue, the less time you’ll spend triaging and refining it in the future.
• You need to be able to easily jot down your own ideas.

Triage

• Triage works best if you have a clear, finite number of issues to go through and you finish with a “zero inbox”.
• It’s best to group tasks for the distant future by module/feature. Tasks for the immediate future are best grouped by time.
• You need a system you can trust to serve you the right information in the future when you finally need them.

Plan

• You usually need to balance working on small improvements of the existing features, maintenance or bug fixes, and new features or initiatives. That’s why you need a queue for these tasks so you can easily mix them one by one in the sprints you plan.
• The queue should be refilled every time you take something out, so you need a well-structured “warehouse” of tasks where you can easily find the most valuable ideas.
• If something needs to be done at a specific time, it’s great if you can instantly place it in the right sprint.

Refine

• If you’re serious about breaking down bigger tasks into smaller ones, you’ll need a single place to keep the high-level requirements.
• There should be a single source of truth for the business acceptance criteria, preferably with a place for discussions.
• POs and stakeholders need a high-level plan, but teams need a low-level one. Specialists from different fields (i.e., UX/UI and IT) usually need a separate space to keep requirements and checklists specific to their domain.

Execute

• This step should ideally be a natural continuation of the previous ones. If we did everything right, planning a sprint would only be a matter of calculating capacity vs. complexity.

That’s how I imagined my ideal process. Thinking a little bit more in scrum-specific terms, I visualized it like this:

A high-level map of the product managment process

Translating the vision into practice

Visualizing the process instantly led me to a conclusion that I need to change a lot about my setup and the inherited model of using Jira.

Let me show you the setup I ended up with, and then explain how all the parts fit together.

The new setup of the Product and Teams projects

Here’s a quick summary of the setup:

• The Product project has 2 separate boards — one for a Warehouse and the other for the upcoming sprints and a short Queue of the most important issues.
• All new issues that are not team-specific are created in the Product project’s Backlog, which is shared between both boards. It’s my inbox that I regularly clear to zero (i.e., an empty backlog).
• From the Backlog, I move them either to the Warehouse or to the Planned board, keeping the Backlog empty (following the zero-inbox principle).
• The Warehouse board has module-specific sprints, so the issues are grouped thematically.
• On the Planned board, issues are placed either in the current sprint, one of the upcoming ones, or the Queue.
• I try to keep the Queue under 20 issues.
• We keep all business requirements in issues in the Product project.
• Using simple automations, we create issues in Teams projects that contain only implementation details and are linked to their “parent” issues in the Product project.

That’s how this setup maps to the process you saw before:

Mapping the Jira setup to the high-level process

The main benefits

Migrating to the new process was such a relief. These are the major benefits I noticed:

• I am certain that no issues are overlooked. My inbox (Backlog) is my “to-do list,” and if it’s empty, I know all new issues were processed. It comes with peace of mind.
• I can plan work at a higher level, not worrying about messing with my team’s backlogs and vice versa.
• It’s easier to align teams around PRODUCT goals, creating the canonical agile teams that are not organized around skills but business needs.
• If the teams are uncertain about prioritization, they can always make sure it’s aligned with the product’s project.
• Whenever a new issue is reported, it’s much easier to make sure it’s not duplicated.
• Business requirements don’t get scattered, and everyone can raise an alert if they think something’s missing.
• Our stakeholders actually understand what’s happening and what to expect.
• Whenever we start a new initiative related to a module, we can quickly check its warehouse to see if there are any low-hanging fruits we can address.
• Issues with a specific due date can be placed in an upcoming sprint ahead of time so we don’t need to remember about them until it’s time to work on them.
• It’s really easy to move issues between boards using the status field — much better then moving tickets between projects (which is horrible in Jira).

Needless to say, these benefits were exactly what we were looking for and the reason this process is still used after over 2 years.

How to implement it?

There are a few key implementation details that make the system work. Let me guide you step by step on how to set up the Product’s project and Team projects so you can benefit from the setup as well!

Create the Product project with Warehouse and Planned boards

Naturally, the first step is to create a dedicated project for product-level issues. I personally use a “company-managed” project in Jira.

Use the Scrum template to have the Backlog feature enabled by default.

Every new project comes with one board by default, so the next thing to do is to create a new board. In board configuration, name one board Planned and the second one Warehouse.

And now for the most important part — how to segregate issues between these two boards. I do it based on issue statuses, using 3 “to-do” statuses:

• To do (for new issues)
• Queued
• In warehouse

Then, for both boards, you set up a custom filter query:

→ Planned

project = [PROJECT KEY] AND status not in ("In warehouse") ORDER BY Rank ASC

→ In warehouse

project = [PROJECT KEY] AND status in ("To do", "In warehouse") ORDER BY Rank ASC

This setup allows me to quickly move issues between boards. Moving them between projects is still a gruesome task, but statuses are modified easily in any context.

The “To do” status is included on both boards because I use it only for new issues in the Backlog, and I want to see them on both boards.

Now, let’s harness the power of sprints to neatly organize our issues on both boards!

Setup sprints and epics

Naturally, the “sprints” feature was created with a different use case in mind, but they can also serve as “boxes” for organizing issues.

I use a different sprints setup on each board.

Sprints on the Warehouse board

As mentioned, Warehouse issues should be organized thematically, so by modules or features. The setup here is pretty easy then — simply create a separate sprint for each module.

Unfortunately, moving sprints around is also a pretty tedious process in Jira, so I recommend starting with a desired order in mind and I think sorting the sprints alphabetically makes the most sense.

Additionally, create an epic for each module as well. They’ll come in handy later. Here’s a simple example of this setup:

Sprints and epics on the Warehouse board of the Product project

Sprints on the Planned board

On the Planned board, issues should be organized chronologically, as it’s the place where we plan the most immediate future. My recommendation is to create one sprint for the Queue and then as many actual sprints as you need (between 5–10 ahead in my case).

One suggestion is to keep a consistent naming for the sprints — it’ll help us with automation later. I simply use the project’s key + starting date as the name.

As for the epics — on the Planned board I map them to actual initiatives we run. Let’s say you have an e-commerce module and you decide to improve the checkout experience. You’d still have an “E-commerce” epic in your Warehouse, but on the Planned board, you can create an “Improved checkout” epic. That allows you to actually close epics when they’re done and even easily build a roadmap out of them (but it’s a topic for a separate article).

Here’s an example:

Sprints and epics on the Planned board of the Product project

Sprints in your Team projects

I mostly give my teams autonomy in terms of organizing their projects, but since we all work in the same cycle, each project is basically organized the same — they have one or two upcoming sprints set up + their own queues for maintenance and team-related tasks.

When we plan a sprint, they know they can allocate a certain percentage of a sprint to these tasks.

An example of a Team project (IT), with an isolated warehouse forMaintenance

Another example of a Team project (UX), working on the same app, but with different maintenance tasks

Helpful automations

We use different automations extensively, but since they might not be relevant to your use case, I’ll only share the ones I find the most important for this setup to work.

To simplify automation rules I share below, I’ll use MYAPP as a Product project key and IT and UX keys for Team projects. You can replace them with actual keys from your projects.

👉 Important note: Having these automations set up is very helpful, but it’s not required for this process to work. If you want to give it a try at first, you can test it manually. However, they save a lot of time on the most common operations.

1. Link an issue by using its key in the summary

Arguably the most important automation we have. Whenever an issue is created in a Team backlog, we can link the “parent” product issue by putting its key in parentheses.

For example, if I create an issue IT-432 in a Team project with summary Add front-end validation (MYAPP-123), it will be automatically linked to the MYAPP-123 issues in the Product project.

Having the issues linked is important because it allows me to quickly monitor implementation progress from the Product project.

Link issues between Team and Product projects by putting an Issue Key in a Summary

How to set it up

1 — Select Multiple issue events trigger and pick Issue created and Issue updated.

2 — Create a {{smart values}} condition and input:

• First value: {{issue.summary}}
• Condition: contains regular expression
• Regular expression: \(MYAPP-\d+\)

3 — Select a Branch rule / related issues:

• Type of related issues: JQL
• JQL: key={{ triggerIssue.summary.match("(MYAPP-\d+)") }}

4 — For the Branch, select action Link issue:

• Select a desired relation type
• Select Trigger issue

2. Quickly clone product issues to Team projects

This automation helps you quickly create implementation issues from a product issue. With one click, you can create an issue that is automatically linked and even set a custom description template or any other fields you need.

Quickly clone Product issue to Team projects, keeping its Issue Key in Summary

How to set it up

Once again, I’ll use the IT Team project as an example.

1 — Select Manual trigger

2 — Select action Create issue

• Select a Team project and issue type
• Use this template as summary IT - {{triggerIssue.summary}} ({{triggerIssue.key}})

I use the Team project’s key in the beginning of a summary to quickly differentiate implementation issues from the main one.

If you didn’t set up the first automation (linking issues based on issue key), you can add a next action to link the created issue with the trigger issue manually.

3. Set status based on sprint names

The last automation makes the “Triage” process much easier. Every few days I send new issues from the Inbox (backlog) to the Warehouse, the Queue, or the Upcoming sprints.

Since boards are separated based on statuses, it’s much easier to simply select a sprint and have the status updated automatically.

Sync sprints and statuses

How to set it up

I use MYAPP as an example key of the product project. Replace it with your actual project key.

1 — Select Multiple issue events trigger and pick Issue created and Issue updated.

2 — Select the Issue field condition:

• Field: Status
• Condition: Is one of
• Value: To do (or other default status you use for new issues)

3 — Select If block and add two {{smart values}} conditions:

First condition

• First value: {{issue.sprint.name}}
• Condition: contains
• Second value: MYAPP -

OR second condition:

• First value: {{issue.sprint.name}}
• Condition: contains
• Second value: Queue

4 — For the If block, select a new action Transition issue and pick the Queued status.

5 — Select an Else-if block and add an Issue fields condition:

• Field: Sprint
• Condition: Is not empty

6 — For the Else-if block, select action Transition issue and pick the In warehouse status.

Summary

If you’ve followed the guide up to this point — congratulations! I know it’s a lengthy piece, but in retrospect, this new setup was one of the most important process changes I’ve ever made. It’s still making my life easier after all this time, and I’m really happy to finally share it with you and others who might be overwhelmed by ever-growing backlogs.

Let me know in the comments if you successfully implement the flow in your project! 💚