How to Do Product Backlog Management Using Jira Software: Our Experience

Learn how to organize a product backlog management process in JIRA to achieve maximum efficiency when outsourcing software development.

Maybe it’s a fintech app using data analytics to deliver more personalized options for the customers. The product owners know what they want that app to do and the features that it should have (a user story and list of product requirements).

They also know that they need to find a software development agency that can take that idea and transform it into an amazing product that will be user-friendly, engaging, and ultimately bring in more revenue – a development team that is established, expert, and has the right backlog management tools and people to do the job.

At Romexsoft, we believe we have those right tools and people. In fact, we have been in the business of software development for over a decade and have developed a project management model that combines our skilled expertise and JIRA – a project management product developed by Atlassian, that provides all the tools for product backlog management.

What is Product Backlog Management?


Source: Atlassian Documentation

A product backlog is, in simple terms, a “to do” list. In the case of software development, as in any project, this “to do” list has to be organized and prioritized.

Think in terms of a new home construction, as an example. Walls cannot go up before the foundation is built; roof cannot go on until the walls are built. And none of this can happen until goals and an overall blueprint is hammered out between the homeowner and the builder and his team.

And how tasks are organized, prioritized, and completed is the difference between an amazing home (software product) and one that is mediocre at best and filled with issues at worst.

At Romexsoft, we learned early on how to organize a product backlog in JIRA software, to build superior software products for our clients. In our minds, it is the best framework for overall project management and documentation of every step in our process from concept to release. And clients who outsource software development to us seem to absolutely agree.

Our Product Backlog Management Process

Here’s a detailed outline we follow on each project. You can use it to model your process and get the basic idea of how cooperation can be established with an outsourcing partner.

Once we contract with a product owner (a client) for development, there is a standard process for going forward.

Phase 1: A Project Manager is Assigned Based Upon The Details of the Product

The project manager and the product owner develop a list of goals, which become a roadmap of sorts. These goals are based on user epics and stories – exactly what is it that the user will do and be able to do with this product?

In the example of a fintech app, one epic might be how the users’ accounts are managed. The stories within that epic will include such functions as how and what data users need to “feed” to the system; how additional information from 3rd parties (e.g. banks) will be accessed, and what personal assessment tools are available.

Each of the epics and subordinate user stories is developed into a list of product requirements for the development team. Depending upon the discussion with the client, prioritization will be outlined.

For example, it may be determined to develop and deliver one complete epic first or to develop stories within epics that may be interrelated. In the end, the PM will create a backlog in JIRA.

Phase 2: The Product Roadmap Review Stage

At this point, the PM gathers the assigned team and reviews the entire JIRA roadmap backlog.

We call this meeting a Story Time and it’s typically held one week before starting the sprint.

The critical goal in this step of the process is that every team member gains an intimate knowledge of the whole picture, each of the product stories, the priorities for development, and the timeline involved. It is at this time that questions of clarification for the product owner can also be developed.

The main goal of Story Time is to develop a clear understanding among the team of what should be done, how it should be done, and what business value it will deliver.

The beauty of product backlog management using JIRA software is that the entire roadmap is clearly visualized, and everyone on a team can provide input on the process from the very beginning.

At this point, we are ready to bring in the product owner once more to get clarifications and finalize the sprint backlog priorities.

Phase 3: Backlog Grooming Sessions

The consequent meeting with the product owner is called a Product Backlog Grooming Session. This meeting is to ensure that prioritization is right. And this is only one of many product backlog grooming sessions.

To maintain a healthy product backlog in agile, grooming sessions occur after each iteration. It is important for the product manager to understand that to manage product backlog while outsourcing software development, he should embrace an executive role and be a proactive communicator.

It is during this step that statuses are set for each part of the roadmap – on hold (task added to the sprint but placed on hold; waiting for approval (new stories may be added but not yet approved by the PM); open (ready for development) and so on.

When we build a backlog in JIRA, with stories/tasks, we use Scrum project management, because a Scrum board is automatically created within JIRA and tasks are a easily dragged and dropped. Once we have the board filled with statuses and priorities, we are almost ready to begin Scrum sprints of development.

As a result of this stage, we form the final product backlog with prioritized features for development:

Product Backlog Management Using Jira

Source: Atlassian

Phase 4: Sprint Planning and Execution

The team meets for the next planning session. The remaining tasks in the backlog are evaluated in case we didn’t have enough information the first time around.

Next, the PM estimates the overall team load and team capacity and starts distributing tasks. We form a commitment list of what we promise to deliver to sprint’s (based on priorities in the Scrum backlog).

Next, we also have an additional list in place – these are the tasks lined up for the developer after he/she finishes the commitment list and still has time within a sprint.

Tasks are then begun. At any given time, a product backlog item will be in one of the following stages:

  • Waiting for Approval – A task may be in the backlog but is not yet approved for sprint.
  • To Do – Tasks are ready to do.
  • In Progress – the coder is working on the task/ticket.
  • Code Review – When one developer finishes a ticket, s/he sends the tick to another developer for a code review.
  • To Verify on Sandbox – Task is tested in a Sandbox environment so as not to affect any other task.
  • To Verify on Stage – A second QA testing on a beta product version.
  • To Verify on Production – Task is completed.
  • Done – Task is closed.

How To Manage Issues with Priorities

jira priorities

Source: Atlassian Documentation

Every task in a backlog is an issue. And they all must be prioritized. Priority simply means the relative importance of an issue in relation to all of the other issues in the backlog.

Developing priorities is best done by a team in concert so that there is clarity among all members and an understanding of common goals and values. And when regular backlog grooming occurs, discussions of modifications in priorities will naturally happen. For example, an issue that one team member is working on may be stalled because another issue that is of lower priority has not yet been addressed.

When development teams learn how to use JIRA effectively to manage product backlog, they will be able to set and manage priorities smoothly.

Traditional development teams can use JIRA’s priority field with its default settings of priority types – blocker, major, normal, minor, and trivial – and tasks can be assigned accordingly.

Agile teams, such ours at Romexsoft, also use the JIRA priority field. As we work via a backlog, a list of all tickets appear based on the assigned priority set by the PM.

The workflow is understood by all team members and can be modified during grooming meetings if needed.

Internal Communication – It’s a Non-Issue in JIRA

JIRA operates as a “full service” software development management tool. No matter how small or large a development team may be, and no matter what hours of the day or night they may choose to work, there is never an issue with communication.

The backlog is there; each member has their assigned tasks and commitments, along with additional tasks, should current ones be completed early, and each member knows exactly where every other team member is in the process – those statuses are all posted.

The other critical communication component of any Scrum team is a brief meeting, no longer than 15 minutes, on a daily scheduled basis. These can be held via video-conferencing if necessary, or face-to-face.

At Romexsoft, these are never optional. The purpose is for each team member to report on what s/he accomplished the day before and what the work is for the day. And this is the time to point out any blocks that have reared their heads so that solutions can be crafted. This practice builds accountability into the entire project and results in smoother execution and more rapid delivery.

So this is our “recipe” for delivering quality products on time. We hope you’ve enjoyed this “behind the scenes” overview of product backlog management and will now have a better idea of the software development processes!

And if you are interested in partnering with a mature development team with streamlined process, Romexsoft would be delighted to share our expertise!

Serhiy Kozlov
Serhiy Kozlov CEO, Romexsoft
Share The Post