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.
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).
These details about each item in the Product Backlog are visible in the Jira Backlog list view by default:
Jira comes preconfigured with some work types, listed below. You can create new categories depending on your team needs.
- User Stories
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”.
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.
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.
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.