How To Build Right Product Backlog Structure

Featured
33349 Views
0 Comments
32 Likes

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.

Share backlog management principles with your team. Tell them how will you manage the requirements.
  • 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.

Things you have to use in Jira to manage the product backlog

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.

Epic - is a large amount of work that can be broken down into smaller parts. I create an epic when the development of the particular feature takes more than 3 days. But do not rush to create epics for each case, in a couple of months you will get a mess. It is necessary to think carefully and create an optimal number of epics. You have to review functionality that you aware of so far, then break into logical blocks and think, what will be epic in your case.


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.

Working with user stories right on the "board" I can highlight the following advantages:
  • 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.

Section name Section goal
Comments
Backlog

Here is placed everything you have not yet started to work on.
Once I get a new requirement I create a user story and put it into backlog if only these requirement is not related to the feature I’m currently working on. In this case, I will put it directly into “BA in progress”.

The source for such of requirements could be:

  • email
  • pictures you got on the meeting
  • plain text in narrative form
BA in Progress
This section is one of the busiest. Here are placed users stories which are under development by PO/BA on the daily basis.
Product owner transfers user story with a high-level description to this section and starts working on it. It’s a place where decomposition happens.
Ready for Grooming

In this section should be stored only those user stories which are ready to be groomed by the team.
Each user story must be already reviewed and approved by the customer.
The minimal definition of done for the story in this section:

  • requirements are clear and without ambiguity
  • mockups
  • mock data if needed

On the each grooming session PO/BA picks up user story one by one and discuss it with the team. If the team is ready to estimate there are no additional open questions, then the US can be moved to “Ready for development”.

Ready for development

The goal of this section is in the clarity of items which are ready for development. By saying “ready for development” I mean that each user story

  • has been approved by the customer
  • has been revised at the “grooming” session and has a final estimate

Example:

  • Project velocity is 100 SP
  • There are 3 teams which take 20/30/60 PS per sprint.
  • Currently, the total amount of user stories in that section is 15 which is 90 SP.

Summary:

  • Your project is lacking 10 story points to fulfill velocity on 100
  • The probability that you will be able to take all of them into the next sprint and cover velocity for 3 teams is 50/50. There are could be technical or business dependencies which will not allow you to take all of them in one time.
  • Always strive to have at least 1.5 times more than the entire project velocity. (in this case 150 SP). Then you will be able to pick up those stories which fit your velocity/capacity and needs at the certain moment.
Next Sprint #N
This section is needed to keep user stories which are planned by BA/PO to take into the further sprint. The content of this section can be changed at any moment. 
User stories and bug are sorted from the top to down based on the business priorities and then technical.
Current Sprint #N
This is the current sprint for a certain team. There are mostly user stories and bugs that were moved from “Next Sprint #N”.

Each user story must be split onto sub-tasks. Each task must be estimated in hours

  • FE - front end
  • BE - back end-QA - quality assurance 

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.

Why do you need it?

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.

My technical skills & experience help me in the everyday routine not only with DEVs but also with a customer. I can ask the right questions at the right time and predict problems in the very beginning.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC