How To Build Right Product Backlog Structure

In this article, I want to share my knowledge on how to manage product backlog using Jira. The article will be useful not only to business analysts or product owners but also to scrum masters, project managers. Basically, anyone who works with backlog and requirements on a project will benefit from reading it. There are certain rules and approaches that you have to follow to achieve good results.

Before we take a look at it I want to point out that this approach is not a market standard yet. However, over the last 3 years, I’ve completed a good number of projects using the approach I’ll be describing here

On the image below I tried to emphasize the main activities and processes that should be presented in your project. You also have to keep in mind that each artifact and process has own goal and definition.

https://ibb.co/WPhbnsd

Basic recommendations and prerequisites

You have to configure everything before the first development sprint starts. it will be pretty hard to change things after the project starts. It is necessary if we want to put the product development on the conveyor. Building a pipeline for managing requirements and backlog solves next problems

• Reducing the cost of the backlog maintenance
• Making backlog management process transparent
• Providing the vision to everyone

To avoid duplication of the information in your project put all user stories you have to a backlog as early as it possible. Of course, those stories will have high -level requirements and it is enough for the business analyst and customer at this moment of time. By using Jira from the start you reduce the number of sources which you’ll need to manage requirements. Keep in mind that you have to train other project participants to use Jira for all activities which are related to the requirements and backlog management.

• What processes will be used
• Who and when should attend the certain meeting
• What you expect from the team
• What the team should expect from you
• When and how will you supply them with requirements which are ready for development?

The process of managing backlog should be transparent for each of project members, no matter who this person is, a regular developer or marketing manager on the client side.

Tell people how the requirements will be collected, clarified, what the client is responsible for, and what you are responsible for as a contractor. It is very important to provide the client with access to the software that you will be using to manage the requirements. This article is about Jira, so make sure that customer has access to the project as early as possible. Without access, this approach will be ineffective.

A small recommendation for project managers, do not force business analysts and designers to create subtasks under specific user stories to track their time. It is useless in this context. The work of the designer and business analyst is quite creative, so it’s almost impossible to guess how long it will take to complete a certain task. According to the plan, the analyst can schedule 10 hours to develop feature “X”. But in reality, it could take two times longer, because of unexpected meetings or problems.

Board - displays issues from one or more projects, giving you a flexible way of viewing, managing, and reporting on work in progress. This concept works for SCRUM model.

Version - represent timestamps in the project. In my practice, I always use naming like this "R.1" and "R.Next" by default. All requirements that appear in the process of interaction with the client in the current release should be captured and not lost. When I understand that certain request is not for the iteration, I create a user story for it and put in R.Next.

Tags - are keywords by which you can easily group/find certain information. For instance, in my projects, I often use tags like (WEB / APP / Integration). To quickly search for the necessary information on different requests from several people (QA / Client / DEV). Tell everyone what tags have been created and the reasons behind them. If you want to avoid chaos regarding tag management on the project, tell the team that disorganized tag creation will lead to problems.

Components - are subsections of the project. They are used to group the project into smaller pieces. I use components for modules in the application. For instance, the module could be “bonus processing” or “business processes engine”. It’s not necessary to use it, but it could give an additional level of decomposition.

Filter - is a simply powerful tool that allows you to simplify the process of finding data or analyze the data on a daily basis. I recommend you use quick filters on the top panel of the board itself.

Issue workflow - is a tool that allows you to set up a sequence of statuses and ways to change them for a particular type. Jira has standard processes for different types. I recommend you rethink standard flow.

User story flow on the last project

Task flow on the last project

User story - is a separate type that I always create on projects. It is necessary to avoid confusing everybody the terminology. You can also call it PBI (Product Backlog Item).

Task / Sub Task - is used for a more detailed breakdown of a user story by developers and QA. Tasks are needed first of all for the developer himself so that in a week he/she can remember what needs to be done in a certain user history.

Bug - is used to fix problems/shortcomings during development. We will talk about bug management in a separate article.

Jira for backlog management scheme

Let's take a look at all of these arrows and rectangles. The main concept is in visual backlog buckets which are nothing else as the phantom sprints. It makes possible to quickly segment user stories according to different criteria, as well as minimize the number of open tabs with Jira in the browser to get information.

• Moving stories from one section to another with drag & drop
• A quick search for information through the search of the browser itself
• Quick filtering by several parameters - Release + Epic + customizable quick filters (Customer OK / Customer Review / and so on)
• Information is broken into the logical pieces which in front of your eyes.
• Quick work with a specific user story after finding it

The minimum set of required sections in my concept is following: Backlog / BA in Progress / Ready for Grooming / Ready for Development / Sprint #N / Current sprint #N. This structure will allow you to solve a huge amount of problems that are associated with requirements delivery to the development team. It helps to understand current situations with an entire backlog.

We need to talk about the “CR Bucket” section separately. The presence of this section depends on whether you use such term as “Change request” on your project or not. For product companies, I do not see any reason to implement "Change Request" process. Change management process is used to solve a disagreement between customer and vendor regarding “scope creep” questions. It’s important to know that the logic behind the science is very similar to what you gonna have in the regular requirements management process.

I would like to mention the main characteristics of well-organized backlog which are (DEEP / INVEST / DIVE). Those are well described in this article so I wouldn't duplicate text here. https://blog.versionone.com/product-backlog-is-deep-invest-wisely-and-dive-carefully/

Defining features/user stories which should be taken into the next sprint must be controlled by the responsible person. I did not specify a specific role, because depending on the project, this role may be called differently and perform different duties.

In order for this solution to work, you need to use labels and spread the idea of it through your and client team (those who will be responsible for approving / signing) the requirements. I give you the following set of labels and a simple process:

• CR (Change request) - is used to mark certain user stories that are considered as a change to the specific requirement. Set by the BA of the vendor.
• HLE (High-level estimate) - is used to show that the estimate of a given user story is high-level and certain assumptions are present there. Set by the BA of the vendor.
• Customer_Review - is used to indicate the user story which is ready for review by the customer's team. Set by the BA of the vendor.
• Customer_Hold - is used to highlight that a specific user story needs to be improved by the vendor team. The customer is not ready to approve it. Set by the responsible person from the client side.
• Customer_Approved - is used to highlight a specific user story which is approved and can be taken into development. Set by the responsible person from the client side.

How does it look like in reality?

You might think that this approach is cool only on paper and theory. But here is a real example of the structured Jira from one of the projects.

https://ibb.co/XpnJsGR

Similar concept to mine was discussed at “Atlassian Summit US 2017”, here’s a video for you.

In order to have good product quality, high speed of development, production requires a stable supply of requirements with exceptional quality.

A development team is a plant that produces a product at each iteration and the worse the raw materials for your plant are, the worse the final product will be or the higher costs for the production of this product itself.

If you want to bring your development team or project to a new higher level, then this scheme is for you! If you have any questions on the implementation or adaptation of all things above, write to me in any communication channel.

Author: Sergii Alekseev Hello! My name is Sergii Alekseev and I live in Kyiv, Ukraine! I have been working as a business analyst/product owner for more than 8 years. During that time, I participated in many projects in different domains. I was able to perform various duties depends on the project goal and team size.

Many times, I was involved in presale\discovery stages. I know how to get relevant information from a customer.