Manage your Product Backlog with Jira

If you want to manage your Product Backlog with Jira, this is a good place to start learning what you need to make the most out of it. I will specifically go through the Product Backlog view, the list and detail view, Prioritization and Dependencies Mapping.

The Product Backlog view in Jira

In each project there is a section in the left navigation bar called Backlog, where a structured list of all work lives. When you open it, there is usually something similar to this. This one is taken directly from the Jira docs and may differ from what you see in some details, as the Atlassian team makes continuous improvements in the tool.

An annotated sample Kanban backlog (with an issue selected), with Backlog and Selected for Development as board columns.

In the left half (1 & 2) of the Product Backlog view, you have the list of work items. It is ordered by priority and separated in one or more Sprints (1), and the remaining of the Backlog (2).

Sprints in SCRUM are time boxes that have a set goal and a list of related work items that are feasible within the time and capacity of the team. You can read more about Sprints in this blog post. Each Sprint has an associated Sprint Backlog, a section of the Product Backlog with a lot more definition that’s often consumed and worked on by team members using a Kanban board. The Sprint Backlog and the Product Backlog are not to be mistaken. Make sure these concepts are clear!

These details about each item in the Product Backlog are visible in the Jira Backlog list view by default:

Issue type

Jira comes preconfigured with some work types, listed below. You can create new categories depending on your team needs.

  • Epics
  • User Stories
  • Bugs
  • Tasks
  • Subtasks

Issue name

The issue name is often visible in different views and reports of Jira and other issue management tools, so define a convention for naming issues early on to avoid headaches. My personal preference is to follow the common advice of verb+object, but this is how I apply this convention to the specific needs of the different issue types.

User Stories naming convention

Use the central block of the conventional user story format, “Like a publication” Add the complete user story format including a clear goal or benefit and a detail of the user or RBAC in the issue details.

Tasks naming convention

Use an action verb and the object affected by the task. “Write documentation”

Bugs naming convention

Use a verb, an object and a consequence whenever possible, like “Adding a new profile image breaks the user profile design”.

Epic label

When used right, Epics are extremely useful for Product Managers. In Jira they can have a name and a color code. I encourage you to give your conventions and organization a thought to get the most out of the tool.


Jira allows you to define the one responsible person for the completion of a task. Beware that this person in many times more a supervisor than an executor. This happens specially in User Stories or Tasks that need a coordinated effort to be completed. If you need to assign more than one person to a card, you can use custom fields. Jira comes with optional fields for reporters, reviewers, supporters, approvers…


Jira cards are associated to a unique alphanumeric reference. This is very practical when referring to tickets in meetings. It also lets you print your favorite or most dreaded tickets in t-shirts or mugs without disclosing confidential information.


Jira comes with icons and labels for high, low and medium priority. If you have some management experience you know using these three priorities often leads to funny situations. Instead, I recommend you default to relative priorities.

Issue detail view

When you click on a work item in the Backlog a detail opens to the right.

You can also click on the issue reference to access a full screen detail view. You will find yourself preferring one option or the other depending of the type of work you’re doing. When I review my backlog I tend to keep the list visible and to use the right panel. In meetings that are about a specific task I tend to use the full screen view.

Issue Description

The Issue Description should include a complete description of the work. Over the years I have come to define a structure that I can easily apply to most of the teams I work with.

  • User Story: Writing the complete user story makes it cristal clear and keeps the focus on goals and outcomes instead of in implementation details.
  • Current Implementation: A detail of the current solution and its flares, or a clear, explicit indication of no pre-existing implementation for a given user story.
  • Suggested Implementation: A details of the suggested steps to bring value to our users.
  • UX/UI: A link to the graphical explanation of this experience, be it a wireframe, a workflow, or a story board. I’ve used different tools in the past, and we’re currently favoring Figma links for this section.
  • Acceptance criteria: I’m guilty of leaving these out in some smaller user stories, but I am often angry at myself at review times. I find a quick short list of acceptance criteria makes it much easier to know what the expected behavior is and makes QA much, much easier.

I like to include all of this information in the description field of the issue in Jira. I also make sure to update the description as meetings happen and details are refined and I recommend you dedicate time to this too, as it can be hard to scroll through comments to find a conclusion when discussions get long.

Some teams like to keep these definitions on a linked Confluence page or on a linked or referenced external document. Whatever flow you choose, please never rely on just an issue name to communicate a work requirement.

Custom Fields

Simplicity is the ultimate sophistication, but if you need moar for your backlog, Jira has plenty of moar for you. Jira admins can create custom fields that are automatically added to work items depending on their types.

Product Backlog Prioritization in Jira

In SCRUM and other agile product creation approaches, priorities for work items should be assigned thinking of customer value first and mostly. The priorities in this context are also in relation to other items in the Product Backlog, not in terms of absolut priorities. Instead of “High priority” and “Medium-low priority” work items now have a changing priority in relationship with other tasks and user stories.

  • The most important or critical features are at the top, the least relevant are at the bottom.
  • Two issues that are closely together have a similar priority, while two issues very far apart have very different priorities.

Jira lets you drag and drop Backlog elements up and down in the list. This makes it easy to use this tool with relative priorities.

Product Backlog Dependencies Mapping in Jira

A Product Backlogs tends to incorporate parent-child relationships as more requirements are identified and added to the list of work items.

Instead of aiming to prioritize at the issue level, I recommend you use Epics and a Product Roadmap. Epics are by definition a collection of user stories and tasks, and subtasks and bugs add up to the list of work items as user stories are refined and tests are done. In this refinement, subtasks are usually added to User Stories and Tasks, too. Be thoughtful about your nested issues to keep the Product Backlog clear and consistent.

Join my newsletter

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: