What is a product backlog and how does it work?

An important element of any agile development project is the backlog. Most people who’ve worked on or near a software project will know vaguely what a ‘backlog’ is (the phrase, ‘add it to the backlog’ is a common refrain), but when pushed for a definition, answers may vary.

Some might say it refers to the requirements of the project listed in very granular form, while some may argue it’s a massive to-do list that details the latest priorities for the development team. Others will view it as an extremely detailed product roadmap. The truth is that it incorporates elements of all of these meanings and more. In this post, we’re going to explore what product backlogs are, how they work in practice and why they are so important to a project.

What is a backlog?

In a recent post on building a digitisation strategy, our MD René described a backlog as simply a “techy name for a list”, and that is essentially what it is – a list of features or requirements, which are then prioritised and worked on by the development team during a digital development project. When we share a backlog with customers, it will typically be in a spreadsheet format, although it can also be viewed within the Jira software that our development team use to manage projects and record progress.

In a project, the backlog is very important. It is the key reference point for our team and our client as it provides the one source of truth, and the de facto, authoritative articulation of the product requirements. If a feature isn’t in the backlog, it isn’t getting created.

Generally, a project backlog will be prioritised in some kind of way, usually through tagging items with categories, or by arranging the list in priority order. Doing this helps to define the work that will be carried out within each sprint, meaning each developer knows what they should be working on at any given time.

The backlog is for clients and their stakeholders too, as it’s a list they give input to, sign-off on and continue to use throughout the project. 

The structure of epics and user stories

So, how does a backlog get created? Well, for us, every project starts with a four-stage discovery process during which we research, understand and then articulate our client’s vision. The output of this process is a massive pile of user and product requirements. It’s this list of requirements that will eventually constitute the project backlog, but before it can be called a proper backlog, the list needs to be prioritised using a MoSCoW workshop. Prioritising features in this way sets out what the Minimal Viable Product (MVP) brief looks like, as well as specifying which requirements and features might follow in later iterations, or are even out of scope. 

With the list created and prioritised, you now have your backlog. Classically, to help make the backlog more manageable, it’ll be organised into epics and user stories.

Epics represent a key feature on a site or app; one epic might relate to the e-commerce experience, while another might relate to user management and another to providing customer feedback. 

Within each of these epics, the requirements are articulated as user stories. User stories describe what users and administrators need the feature to do, and are expressed from their point of view. For example, if we were designing a feature on an app or website for users to give feedback, two of the user stories in that epic might be something like:

As a user, I need to give my consent for the use of my data for GDPR purposes…

As an administrator, I need to be notified when a user has provided feedback…

For the development team, things actually get even more granular as we define the specific necessary tasks from a coding perspective, although this is not something a client needs to be exposed to.

The benefits of a long term product backlog

A backlog can be used and applied to a single project, but they start to assume greater value and importance when applied to the full lifetime of a product. Your backlog won’t just be confined to a single project and then gently discarded, it will be used for future projects and phases relating to your product, or even on an ongoing basis if you are investing in a continual improvement program (CIP). 

When you create a backlog based on user research and feedback, there will inevitably be requests that are not in scope for your MVP or even your second release, but might form the backbone of sprints months down the line. Here, a backlog initially set up for a project starts to become a foundation that can be used and referred to on an ongoing basis. It can also be updated as ongoing feedback from users is received and additional needs and features are identified. 

Setting up a product backlog means it becomes a critical reference tool to:

• Influence your product roadmap and product planning process
• Assimilate and capture ongoing feedback which can sometimes otherwise get lost
• Help support continual improvement
• Aid budget and resource planning, estimating the cost of future phases
• Be used as a data input into a business case
• Support your reporting to management
• Provide an essential reference point for new project team members to get up to speed
• Ensure different stakeholders are on the same page
• And more!

Overall, the product backlog becomes integral to the success of your product, growing into a valuable asset for product management.

Five characteristics of a good product backlog

1. It is actively managed to capture ongoing requirements

A product backlog needs to be actively managed. There needs to be a clear process through which this is done, with assigned roles to capture feedback and feature requests as they arise so they get assimilated into your backlog. User feedback can come from a variety of different sources – from workshops to emails, to meetings. A product backlog should capture everything that might contain suggestions concerning new features for your digital product. Regular meetings between the product team and the development team to review the backlog can also be part of this process. 

2. It is fluid and flexible

A product backlog is not a fixed requirements document. It is fluid and flexible, with the addition of new user stories, changing priorities and even new epics as products and user needs evolve; things can get removed from the backlog, relegated to be of lower priority or even marked as unlikely to happen, for example. 

3. It aligns the roadmap and requirements

Product teams will have a product roadmap in mind that in turn reflects your original strategy and vision. The product backlog essentially aligns your roadmap with your requirements, putting the detail behind the main areas you want to work on and defining the sprints that are actioned. Making sure the product roadmap and backlog remain aligned is key. This might sound obvious, but backlogs can get very detailed, and it’s surprisingly easy to get out of step with your original roadmap and objectives.

4. It is the one source of truth

A product backlog provides one source of truth and therefore needs to be kept up-to-date. Version control is key here, as well as avoiding mistakes like alternative requirements documents. All stakeholders need to buy into the product backlog concept.

5. It is actionable and allows for effective prioritisation

A backlog needs to be usable and actionable, allowing teams to view what’s ahead while also helping to prioritise what’s coming up. Here, the ability to filter the list in a spreadsheet by priority plays a role, avoiding the nth level of detail and ongoing management. A product backlog should not be overwhelming to use.

Raise a glass for the product backlog

Product backlogs are not only essential for agile development, they’re integral to product management. Your product backlog can be your best friend, and it’s worth investing the time to manage it properly. Cheers!