What Is a Backlog, and How Is It Used in Projects and Product Development?

Let’s not beat around the bush — what is a backlog? It’s a tool for managing requirements on a product, service, or project. Paraphrasing the Scrum Guide , which was updated in November 2020, it’s an open, ordered list of requests aimed at improving or completing the value of something — whether that’s a product, a service, or a project.

The backlog, a prioritized list of requirements for a product or service, is an ideal breakdown mechanism for managing requirements when they’re variable and highly dynamic. Unlike other breakdown mechanisms, like the project’s Work Breakdown Structure (WBS), it has several particularities we’ll get into below, and they’re key to its success in managing adaptive projects and developing products and services.

What Elements Go Inside the Backlog?

The backlog is an open list of items. It can hold specific requirements for a project or product, it can include tasks, it can include use cases or user stories, and, most importantly, it can hold a combination of all of them.

The Backlog Can Only Hold User Stories

FALSE, FALSE, ABSOLUTELY FALSE!

This is something I see all the time as a consultant and change agent. Teams suffering, trying to document every single one of their requirements and backlog items as user stories. It’s a tremendous waste of effort!

Every way of writing a requirement fits the specific nature of the product or service being developed. Some “types” of requirements promote autonomous development, while others are more detailed and geared toward strict compliance with certain conditions.

The team’s maturity is also an important factor to consider when deciding how detailed and thorough the information accompanying the items on this prioritized list should be.

Why Keep “Backlog” in English Instead of Translating It?

Personally, I don’t like translating the word backlog, because Spanish doesn’t have a single word that captures the same meaning. Some years ago, when I volunteered on the translation team for the PMI’s Agile Practice Guide , this was one of the hardest discussions we had, so here are some of the most popular translations in the context of projects and agility (in Spanish: pila, lista priorizada, lista emergente y ordenada, lista de trabajo pendiente).

As you can see, these are broad terms that are hard to pin down in Spanish, and just to illustrate why the word is so complex to translate, here’s an example.

Sprint burndown chart is a visual representation of the sprint backlog remaining work through the days.

In Spanish, this would come out as something like:

El diagrama de quemado de la iteración es una representación visual del trabajo pendiente de la lista priorizada de trabajo pendiente de la misma iteración a lo largo de los días.

To avoid this, we’d have to call the backlog by a different name in every situation. List, prioritized list, pile — and there’d be no way for someone who’s still learning to understand that the list, the prioritized list, and the requirements list — however you translate it in context — are all the same instrument.

As you can see, it’s not a simple term to translate, especially not with words as out of context as pila — stack. [ref]I’ll admit that some translations within the project management and agility context — backlog to pila, scheduling to programación, feedback as realimentación, burndown chart to diagrama de quemado, and burnup chart as diagrama de quemado hacia arriba — make me deeply uncomfortable.[/ref]

What Types of Prioritized Lists Exist?

Before we start, I want to make clear that, although Scrum is trendy these days, the backlog isn’t an instrument exclusive to Scrum. For example, XP defined the backlog very well decades ago already. So, let’s begin:

1. Product or Service Backlog — Product Backlog

When we talk about the Product or Service Backlog, we mean all the requests associated with the development, maintenance, or operation of a product or service. The product backlog includes, among other things, tasks, deliverable-related requirements, improvements, change requests, maintenance work, and everything worth keeping “on the radar” for a given product or service.

2. Project Backlog

The Project Backlog is useful in some specific contexts, and it isn’t a wholesale replacement for other breakdown tools like the Work Breakdown Structure (WBS). In a project with variable scope, using a backlog is more efficient and practical than using a WBS.

WBS or Backlog to Manage the Breakdown?

This can be a deep and lengthy discussion, but here are 3 KEY differences to help you choose between a WBS or a backlog as your breakdown tool.

1. Nature of the project scope. If the project has a closed scope, and part of the management job is keeping additional requests in check, the WBS is the right choice. If, on the other hand, part of the project is about discovering, maturing, or refining the scope of the product or service under development, then the backlog is unbeatable.
2. Not everything is included. One of the hardest things for a project manager to grasp is the fact that backlog items aren’t necessarily committed for delivery. This is the opposite of a WBS. Everything, and only what’s inside the WBS, is part of the scope. In a WBS, anything extra is considered gold plating. The backlog, by contrast, is an instrument that offers priority and order, and so natural changes or discoveries in the product or service development process can bump other features or requests that, in light of new findings, no longer carry the same priority.
3. Beyond the project — operations. The WBS is a closed instrument that aims to contain the entire scope, and it’s therefore not useful in environments where there’s no defined scope. How could we manage a set of unexpected, unanticipated requests for a team? The WBS wasn’t designed as a dynamic, flexible instrument, and although it can receive changes and updates throughout a project, it isn’t a “dynamic element” the way a backlog is.

3. Iteration Backlog — Iteration Backlog or Sprint Backlog in Scrum

The Iteration Backlog refers to a set of things to do or complete within a fixed period of time. In Scrum , 2020 version, the Sprint lasts between one week and one month. In earlier versions of Scrum, or according to other authors, it’s between two and eight weeks. But in general, the Iteration Backlog is the prioritized list of “things to do” during a fixed time period.

The Iteration Backlog isn’t necessarily a subset of the Product Backlog or the Project Backlog. There should, of course, be a relationship between the two when both are used, but part of the iteration planning process is detailing, breaking down, and completing the product/project backlog for the iteration that’s about to start. In that sense, it’s entirely possible for the Iteration Backlog to contain items that weren’t included in the Product or Project Backlog.

4. Portfolio Backlog

Consider, for a moment, that your strategic portfolio — which includes several projects and other components — is a prioritized list. Why not use the backlog at the portfolio level too? Prioritizing is an excellent idea for avoiding what I’ve called the glutton syndrome — the assumption that money is the only factor to consider when deciding to add or drop an initiative from the portfolio.

In Lean Portfolio management, the Portfolio Backlog is a fundamental instrument. It also appears in the Scaled Agile Framework.

5. Program Backlog

When we manage complex products or projects, it’s possible to have the backlog categorized further. Similar to what happens with a program and a project, the backlog can be a valuable instrument for managing pending work and priorities at scale, across multiple teams — of course, when the scale calls for it, meaning when there are enough people interacting that keeping everything centralized both helps and gets in the way at the same time.

6. Team Backlog

If there’s a program backlog, then there must be a team backlog too. If, for the sake of the overall picture, we unify our “pile,” then for the purposes of managing a team — almost always an agile one — we need a reduced, focused version to manage day to day. This is what’s known as the team backlog.

How Do You Properly Manage a Prioritized List?

As we’ve seen, the backlog is an instrument tied to work to be done, whether that’s associated with the scope of the product or service, or with tasks tied to its development, maintenance, and operation. Because of that, the backlog requires a lot of work and effort to stay up to date and not lose value.

In some management models, one person is assigned as the “guardian” or owner of the backlog. In Scrum, this role is known as the Product Owner. But since the backlog as an artifact isn’t exclusive to Scrum, we find roles associated with tending to and maintaining it under different names.

Roles in Charge of Creating and Managing Backlog Items

While this isn’t an exhaustive list of roles, these are the most popular or common ones.

• Product Manager
• Product Owner
• Customer
• Customer Proxy
• Business Analyst
• Documenter
• Project Manager*

Is the Project Manager in Charge of the Backlog?

It depends. The project manager or director is in charge of managing the project scope, and so, if they’re in charge of managing the scope breakdown structure in predictive projects, why wouldn’t they be in charge of the backlog too?

That said, in agile projects, where the backlog shines as the instrument for managing scope, the project manager doesn’t show up as a prominent role. For example, in the Scrum team management model, the Scrum Master and Product Owner roles exist. That’s a clear separation between managing scope — focusing on delivering business value — and managing the team. This creates a balance between wanting to do something and being able to do it. Likewise, this separation of responsibilities keeps the team’s needs and performance from being ignored in the pursuit of business value.

Although it isn’t explicitly assigned, it’s common to find project managers in charge of managing scope — acting as Product Owners — while also managing or directing the team, similar to what could be understood as the Scrum Master role. [ref]Whether a project manager can also act as Scrum Master is always heavily debated. In reality, it happens often. Personally, I consider them complementary roles that, with the right skills, can be carried out by the same person.[/ref]

A Word of Advice for Project Managers

The backlog is a dynamic instrument that, unlike the WBS, requires much more commitment and dedication. If you enjoy owning scope as a project manager, don’t hesitate to bring a Scrum Master onto the team to facilitate and mediate your relationship with the team. Avoid being judge and jury.

Why Do Requirements Change?

The backlog is a dynamic, open instrument. That means items inside the backlog come in, go out, and get reprioritized regularly — under certain criteria and structure, of course, depending on the management model or paradigm you’re using on your project or with your team.

As a result, the backlog is ideal in environments where, for example, feedback is critical to defining the future of the project (or the product). One example of this kind of context is entrepreneurship. Entrepreneurs need new customers, and to get to know them, they quickly and frequently expose their ideas through new products, services, and marketing campaigns. If the response is positive, they dig deeper into that idea; if it’s negative, they “pivot” and keep going.

The backlog accepts and amplifies feedback. A good team uses feedback to improve the capabilities of a product or service under development.

Refinement and Keeping the Backlog Up to Date

Remember that the backlog is a valuable instrument in contexts where the scope of the product, service, or project requires a certain amount of dynamism. Managing the backlog is a demanding task, and a necessary one for the project’s success. It’s not just about identifying what needs to be done — it’s about structuring, prioritizing, and ordering the work to achieve the greatest impact.

One of the activities that’s taken on more weight in recent years is what we used to call Backlog Grooming and, for obvious reasons, is known today as Backlog Refinement. [ref]The Cambridge Dictionary lists, among its definitions of the word grooming, one that has gained ground over the years and is associated with criminal activity. This led to a change in the Scrum Guide’s terminology, from grooming to refinement.[/ref]

In the SAFe framework, backlog refinement is defined roughly as follows: [ref]This translation of backlog refinement isn’t literal and is adapted slightly to fit the context of this article — without changing its essence. To see the original text, I invite you to visit the Scaled Agile Framework page.[/ref]

The backlog should always contain a few ready stories for implementation, meaning ones without major risks, deep uncertainties, or big surprises. Agile teams, by adopting a flow-based approach, work to keep a certain level of “readiness” in their backlog. They achieve this by holding at least one backlog refinement session per iteration, or even per week. During this refinement session, higher-priority stories are analyzed, and the team discusses, estimates, and builds an initial understanding of the acceptance criteria.

Scaled Agile

Tips for Keeping a Good Backlog

I wish I had a magic formula to share on how to manage and maintain a good backlog. I’d surely be a millionaire — but that doesn’t mean we can’t leave a few good tips to improve the odds of having a good backlog on our projects or with our teams.

1. Dedication and Commitment

Unlike predictive projects, the variable and dynamic nature of the scope requires dedication and commitment to the backlog. In Scrum, for example, the Product Owner role is a full-time commitment. Managing the backlog takes time. Forget the idea of reviewing the backlog every once in a while.

Give priority and authority to the person who guards the backlog. All team members, and even stakeholders, are welcome to propose new items, changes, and new priorities for the backlog, but only one person should ultimately accept, dig into, and prioritize the backlog — that’s why I like the word guardian. If you’re doing Scrum, don’t hesitate to assign your best available Product Owner full-time.

2. Incremental Thinking for the Items

The backlog isn’t just a prioritized list. What’s the point of prioritizing if, to complete the top-priority items, I first need to complete the lower-priority ones? This mistake, or agile anti-pattern, is common in many projects that only worry about breaking the plan into iterations, without going deep enough into how to structure deliveries and components to enable continuous delivery of benefits. To avoid it, the INVEST criteria for backlog items was defined.

The INVEST Criteria

The backlog needs items that meet the INVEST criteria:

• Independent (I) — items that, for the most part, are “self-contained” and don’t require other items to demonstrate their value.
• Negotiable (N) — the backlog isn’t a closed element, and so some backlog items get completed and others don’t. That means we must always be able to negotiate priorities and whether or not to include an item at a given point in the product’s life.
• Valuable (V) — if the backlog is a prioritized list of items, well, value is what lets us prioritize it. There may be low-value items in the backlog, but keeping them there once we’ve identified they’re low-value doesn’t make much sense.
• Estimable (E) — as a backlog item gets closer to the top of the prioritized list — meaning it’s close to being considered for the development or production process — it needs to be estimable. In other words, the project or product team must be able to discuss how much effort, how much complexity, and how much risk it carries. To achieve this, the item can be detailed — in refinement sessions — or broken down into smaller components that let the team move forward.
• Small (S) — this criterion applies mostly to Team and Iteration backlogs. Items flow better through the system when they’re small — a basic LEAN principle. That said, a portfolio backlog doesn’t necessarily have small items.
• Testable (T) — in principle, every backlog item, just like every WBS item, should have some acceptance and/or validation criteria. Otherwise, how could we know something has been done and meets the established objectives?

3. Balance Between Anticipation and Adaptation

The backlog is prioritized. There’s a reason for that: focus on what matters most and is most valuable for the product, service, or project. If there’s no focus, there’s no point in prioritizing. So you should avoid, at all costs, trying to anticipate too much at the start of the project, or when the team is just forming. Finding the balance between anticipating with up-front design and adapting is essential to making wise use of the time of business experts and the backlog’s guardian — for example, the Product Owner’s time.

4. Preliminary Prioritization Criteria

Much of the difficulty in prioritizing the backlog lies in the guardian’s subjectivity, or in the diverse interests of all the stakeholders involved. A great technique can be to set up an algorithm, process, or weighted prioritization mechanism that lets you factor in multiple dimensions when prioritizing. Scaled Agile Framework, for example, presents WSJF as a prioritization exercise for the portfolio backlog.

I want to be clear that setting prioritization criteria isn’t about removing the human factor from prioritization — quite the opposite, it’s an auxiliary tool meant to fuel discussion and debate around priorities. We can’t always pick backlog items just because the person requesting them has a bigger office than we do. In English, the term HIPPO — highest paid person in the office — is used to point out those times when there’s no real criteria at all, just the whim of whoever gets paid the most at the company.

5. Percentage Limits and Funnels

Well, if the backlog is a dynamic element, and refinement sessions happen fairly often, it can be a good idea to set limits on the number of new items to discuss, or on the improvements and refactors we take on in an iteration or consider during our sessions.

This can sometimes help keep the focus and avoid an excess of experimentation that, in the end, leaves us with a lot of things to try and few things that actually deliver value.

Similarly, it’s possible to set rules for items to leave, or “die,” inside the backlog — for example, items that never manage to climb up the list and are always displaced by other, “more important” items.

6. Management Tool

Management tools are useful, and they provide a structure for adding, managing, updating, and planning items — everything from sticky notes and acrylic boards to advanced software-based management tools.

Rather than filling a tool up with a lot of information, my recommendation is to be consistent about keeping it up to date: adjust priorities, add new items, and discard the ones that have been completed or are no longer part of the plan — most tools handle a good chunk of these tasks automatically anyway.

Things to Avoid

Well, like any other tool, the backlog comes with several considerations to keep it from being misused or losing its effectiveness on a project or with a team. These problems are:

1. Excessive accumulation. Avoid throwing everything into the backlog. It’s a flexible instrument, but it can’t turn into a memory chest or a junk drawer. It’s common for some people to treat the backlog as an endless wish list.
2. Needing overly detailed information. I mentioned this before — avoid losing the balance between anticipation and adaptation. You need an initial prioritized list to work with, but priorities should dictate what the guardian focuses on. Avoid anticipating everything; the backlog is designed for “complex adaptive” contexts, where part of the work’s scope is meant to include experimentation and feedback.
3. Monolithic structure. Avoid letting every backlog item depend on all the others. That’s no simple task. To avoid it, it helps to develop an entrepreneurial mindset, where big achievements are the sum of many small ones.

Templates for Managing the Backlog

This is a common need. Is there a definitive template for managing the backlog? Of course not. But that doesn’t mean I can’t share a few interesting ones. Here’s a list of templates:

• Backlog Management Tool Built by Sperta Consulting . [ref]Sperta Consulting is the company I’m a partner at. It specializes in consulting, coaching, and training on team and project management and organizational structure.[/ref] This is a tool we use for academic purposes, mostly to discuss the impact of iterations on a project’s progress. Far from perfect, it helps spark deep discussions in the exercises we run in our courses.

• Agile Project Plan Template Built by SmartSheet. It’s a very complete tool — and, as a result, a bit complex.

• Templates for 14- and 30-day Iterations Built by Mitch Lacey and Associates.

I personally don’t use templates in my day-to-day work — or it’s very rare when I do — but they’re very useful for academic settings. They’re easy to tweak and customize to make a point, illustrate a concept, or lay out pros and cons.

These days, it’s more common to use a cloud-based agile team management tool than a shared spreadsheet file.

Final Thoughts

The backlog is a genuinely powerful instrument. A good backlog is key to team agility and the incremental development of products and services. It’s a great ally for agile projects and an essential part of lean portfolio management.

That said, it shouldn’t be thought of as just a to-do list.