The first time I worked with a product backlog, 10 years ago, I didn’t even know I was working on a product (it was an internal billing tool) or what a backlog was (we called it a list of change requests, and we stored them in a spreadsheet).

Early on I started to work on ways to better manage our change requests, and constantly struggled to decide which changes to share (my manager was way better at deciding), and I worked on different systems using Word and Excel wondering why nobody had made an app to manage said change requests.

The year is 2010 and I don’t even know Microsoft Project exists. 10 years forward I’ve worked with basecamp, redmine… and Jira. And I know that my constantly growing list of change requests is what some call a backlog.

Through these years I’ve collected tips and information I wish I had when I was wondering what information I needed for each change or opportunity, how to better communicate why it was a good idea to do it or what we would need to do, in return, to make it happen.

Back then I worked with remote developers, and all the magic happened in a black box. Later on I have had the pleasure of working very closely with development teams, as well as very close to where the decissions are made. These experiences helped me gain new perspectives.

I hope you find my view useful in your way to better product backlogs. 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 start with a definition of Product Backlog and some comments about the kinds of work we may expect to find there. Next, I will introduce the the list and detail views of your backlogs in Jira, for those who use this app.
Last, and only once we have a solid foundation, as this is a very sensitive topic, I am sharing some methods and opinions about prioritization of product backlogs.

If you feel I missed anything or don’t align with some of what I say, I’m always up for a talk about product backlogs and prioritization and the comments are open. Thanks for reading!

1. What is a product backlog?
2. The Product Backlog view in Jira
   1. Issue type
   2. Issue name
      1. User Stories naming convention
      2. Tasks naming convention
      3. Bugs naming convention
   3. Epic label
   4. Assignee
   5. Reference
   6. Priority
3. Issue detail view
   1. Issue Description
   2. Custom Fields
4. Product Backlog Prioritization
   1. Customer value and business opportunity
   2. Effort and confidence

What is a product backlog?

The product backlog is a list of all opportunities and debts related to a product. It continuously changes as new opportunities are identified internally or externally, and old opportunities are materialized or dropped.

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.

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).

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. You can learn more about them in my post about issue types.

• 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.

Assignee

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…

Reference

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.

Priority

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

There are different prioritization frameworks, but they can all be summarized in the following concept: customer value and business opportunity increase the priority of a task, while effort and uncertainty decrease the priority of a task, as it has more probability of getting stuck and affect the development of dependent parallel work.

Customer value and business opportunity

In SCRUM and other agile product creation approaches, priorities for work items should be assigned thinking of customer value first and mostly, and business opportunity next.

How can we evaluate customer value and business opportunities? When prioritizing issues in your backlog, do it with these questions in mind:

• How many users will be benefited from this?
• Have we received direct feedback from users?
• Have we lost any prospects or customers because we didn’t have this available?
• Do we have solid arguments to believe customers will be more willing to pay for what we do if we have this?
• Does having this open the door to a new market?
• Does it remove a barrer to enter a market we have been trying to penetrate?
• Is this something we want to use to position ourselves in the market?
• Is it a differentiator from our competitors?
• Are we doing this to catch up with competitors?
• Does this help us eliminate technical debt?

Effort and confidence

As you may have anticipated this is another criteria that will help us prioritize our backlogs. While doing this, the next set of questions apply:

• Do we have the technical or domain knowledge to execute it?
• Do we have all the information we need to design and execute it?
• How long do we need to understand the scenario and make an estimate?
• Can this be supported by our current infrastructure?
• Can we see any blocks or dependencies?

Mixing the customer value, the business opportunity and the feasibility we’ll be able to start differentiating the issues that bring the most value and have the lowest effort. This is what some call the low-hanging fruit, and while it’s not always the tastiest, it surely is the easiest and fastest to pick.

The priorities in agile contexts are in relation to other items in the Product Backlog, not in terms of absolut priorities. Instead of “High priority” and “Medium-low priority”, or numeric scores, 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.

In Jira, and other product management tools, this is easy to do. 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.

Every now and then you must do what’s commonly known as refinement or reprioritization of your backlog, and rearrange the opportunities to represent the current priorities.

In agile projects, we are continuously learning and discovering new opportunities and more information about the ones we are exploring, so it only makes sense to continuously update our backlog to reflect these findings and learnings.