Is Backlog a list of items or a status of those items?

Question

I'm a little confused about the "backlog" best practice and I would like to educate myself on this. I know the point of it, but the thing is, that I can't tell by definition, whether it's a status of an item or the collection of all items (no matter the status).

I used to work with the idea, that the backlog is a whole collection, which means something like this:

BACKLOG
 - open/pending
 - to do
 - in progress
 - in review
 - closed/done

However, others might argue that the correct definition would make it look like this:

[something]
 - BACKLOG (unscheduled)
 - to do (scheduled)
 - in progress
 - in review
 - closed/done

What resource should I refer to as the correct definition? See following:

A product backlog can be an effective way for a team to communicate what they are working on and what they plan to work on next. ... The product backlog can be represented in physical form using index cards or sticky notes, or it may be represented in electronic form such as a text file, spreadsheet, or one of the many backlog management tools that exist (Agile Alliance).

Perhaps the best way to think of a product backlog is as a “living” document which reflects the progress of the project. It is an ever-evolving list of action items, some of which may be removed further down the line, replaced with more pertinent activities (Airfocus).

or

A product backlog is a prioritized list of work for the development team that is derived from the roadmap and its requirements. The most important items are shown at the top of the product backlog so the team knows what to deliver first. The development team doesn't work through the backlog at the product owner's pace and the product owner isn't pushing work to the development team. Instead, the development team pulls work from the product backlog as there is capacity for it, either continually (kanban) or by iteration (scrum) (Atlassian).

Answer 1

It's a good question. From a Scrum point of view the product backlog and the sprint backlog together encompass all the things that are being done or that are on the list to be done in future. So the term backlog refers to the full list of items no matter what their status. Status information is usually shown against each item on the backlog.

However, I do see some people using Kanban boards with a column labelled "backlog" for the things that are not yet done and not being worked on. There's no definitive one way to label up your board. In Scrum terms, things not in the current sprint are the product backlog, things being worked on are the sprint backlog. In either case those items can have status. If you are using Kanban method then arguably there is no backlog as such - just status.

In short, I would say that backlog is not a status, it's a collection of items, each of which can have priority and status of their own.

Answer 2

Disclaimer: The first time I read the question, I thought it'd have a straight answer. After reading it again, it may not be as straightforward as I originally thought (or maybe I'm overthinking).

---

From Cambridge dictionary, a backlog is a large number of things waiting to be done.

Therefore, once an item is no longer waiting to be done, it shouldn't be considered part of a backlog anymore. Thus, backlog is a transient status for a work item.

For the second question, which definition is correct... why not both? Both are presenting the same core definition: A prioritised list of work items.

Thus, answering the question in the title...

Is Backlog a list of items or a status of those items?

As each work item has a specific status assigned to it, one could infer that the Backlog is a list of items where all items in this list are in backlog status.

Notice that "backlog status" isn't something common to say, though. You could have different statuses associated with the backlog.

The most straightforward approach would be to use a status called something like "to do" (or "requested", or "open") and have this status considered backlog.

Other teams may prefer to have some granularity on their backlogs, so one could have different statuses composing the backlog. Statuses such as "Requested" > "Refine" > "Review" > "Ready for sprint backlog". All these statuses would still compose a backlog.

---

ps.: I avoided differentiating product and sprint backlog for the sake of simplicity.

Answer 3

I think that having an answer to the question is more important than what the answer is.

Decide on what you believe is the purpose of the backlog and make sure it is communicated widely. Work with it for a while and see how things go. If you experience issues, adjust the way the backlog is defined and again make sure everyone is aware of the change.

Answer 4

I think you can define backlog as you see fit, based on how you organize and think about work as well as how you communicate work to your stakeholders. The definition you use needs to resonate.

For me, I like the dictionary definition @tiago wrote in his answer. It resonates for me in that work listed in my backlog has to mean the work has not started or was stopped and is waiting to restart. When work starts, it is no longer resident in the backlog. I differ however in that I do not treat backlog items as prioritized. The reason is that the act of prioritization occurs when I am choosing what work to begin. Your work will meet your prioritization criteria differently based on time, i.e., work item A could be high priority in January but medium priority in June because of environment / legal / business health / whatever changes that occurred during those last six months. Since change is constant, it does not make sense to me that the backlog is "prioritized" except in a moment in time when you are choosing work.

Answer 5

I generally agree with the answers already given, but would like to emphasize the context and purpose of the backlog, which in turn determines its best implementation in a given setting.

Basically, the backlog is the list of items known to need to be worked on but not yet started. As such, it does not include stuff that you don't know yet, and also not stuff that is currently in progress or done. This implies that items within the backlog don't have much of an individual status, although you could call their current estimate and position within the backlog their "status".

In the Scrum example, you have two backlogs, so a single "backlog" status would not suffice. The product backlog is an ordered list of items which are partially estimated and ordered during backlog refinement. Its context is the whole product, and the order of items is determined mainly by the product owner to prioritize what should go into the next sprint(s). During sprint planning, items are moved from the product backlog to the sprint backlog. The sprint backlog is only relevant in the context of the sprint and contains those work items that the team has decided to implement within that sprint. It does not need an explicit ordering, as the team should collaboratively determine if there are dependencies between items, and which items are essential to the team goal.

How you represent the backlogs is something separate, and it might actually be different depending on the tools that you use. If you use a ticket workflow system, it's natural to assign a status to the items that are in a backlog (for a Scrum implementation, you would need status "in product backlog" and "in sprint backlog", or you use some other marker for items that are assigned to a given sprint). Of course you need some ordering marker as well to indicate the product backlog order. If you use paper and whiteboard as your tools, which is pretty reasonable for colocated teams, moving cards between columns as in the prototypical Kanban board makes most sense. The product backlog might even be a physical stack of cards in the product owner's desktop drawer, only to be pulled out and worked on during backlog refinement, or a list of items in a document file.

Answer 6

tl;dr: The Backlog is a list of items, tasks or activities representing work that has to be done; the breakdown of such items and their statuses during the workflow is a Kanban Board.

---

By definition, the (Product) Backlog is a list of items, which contains or derives into the list of activities/tasks needed to complete a step in the process.

The two definitions you reference in your question aren't mutually exclusive, as both of them refer to the backlog precisely as the list of work to do.

It is true that the Backlog can be represented as a "status" of an item; this really depends on the workflow and the way the team better understands it. But even as a status, it still means that all items in the "backlog" status or stage are in the list of work to do.

Now, the confusion can come from the fact that the first definition, and both of your example lists take the backlog as something that is usually referred to in a different way, so these:

BACKLOG
 - open/pending
 - to do
 - in progress
 - in review
 - closed/done

[something]
 - BACKLOG (unscheduled)
 - to do (scheduled)
 - in progress
 - in review
 - closed/done

... and this:

A product backlog can be an effective way for a team to communicate what they are working on and what they plan to work on next. ... The product backlog can be represented in physical form using index cards or sticky notes, or it may be represented in electronic form such as a text file, spreadsheet, or one of the many backlog management tools that exist

... are variations or implementations of a Kanban Board, which is indeed the representation of both the tasks to do/in progress, and their current status or stage during the process. The way such board is separated is entirely up to the way the team and/or the company handle their workflow.

Answer 7

TL;DR

Generically, a backlog is a project or product management artifact that represents potential future work. As such, it's most useful to think of it as a register of future work within the project rather than as a top-level status or a container of work states.

I provide additional detail below on what backlogs are, how to conceptualize them as planning artifacts, and how to visualize them within the scope of a project. However, if you just want to see how an experienced agilist visualizes them and compare that to the hierarchies in your original question, you can skip directly to the last section without the intervening explanations.

What an Agile Backlog Is

I can't tell by definition...[if a backlog is] a status of an item or the collection of all items (no matter the status).

A backlog is really just a bucket of items that are not yet work-in-progress. These items might be incoming requests, to-do items, or actively planned work, but whether or not they are ordered by some metric such priority, value, lead time, FIFO, or something else is generally framework-specific.

In Scrum, for example, the Product Backlog is generally a list of items grouped into cohesive Increments that are then placed into some sort of ordered list by priority. "Priority" is not explicitly defined by Scrum, allowing for priority to be determined by the current needs of the business and the practicalities of the project, except to define it as ordinal and set by the Product Owner. Other frameworks (and even other types of backlogs such as the Sprint Backlog) can and do treat the contents and ordering of backlogs a little differently.

While backlog items can carry metadata (e.g. value, cost, or priority), actual item statuses like "in progress" or "done" aren't among them. If they were tracked that way, they shouldn't be left in the backlog in the first place, as items that are in-progress or some other status (even "blocked") are really work items that are either in-scope for the current iteration or actively work-in-progress.

How to Think of Agile Backlogs

In an agile context, a backlog is a collection of potential work items, primarily used as a place to hold future work. You could certainly partition a backlog in a MoSCoW sort of way, add metadata about how items got there (e.g. as customer requests or as necessary architectural runway), or add other information about its relative value or priority. However, a backlog (especially a Scrum Product or Sprint Backlog) shouldn't really be a perpetual parking lot. From an agile perspective, saying something is basically a "never going to happen" but dragging it along in your Product Backlog forever is an anti-pattern, but you theoretically could.

Having a separate "parking lot" for low-priority items or non-starters is not something addressed by the current Scrum framework, but it's not an uncommon practice when you want to differentiate "future work" from things that are deemed out of scope. However you decide to handle such items, an experienced agilist probably wouldn't consider them backlog items since they aren't really things that are likely to become actual work items.

Since the backlog is intended to be a project/product management artifact or future-work register rather than a work-in-progress state tracker, I think most of your confusion about it would disappear if you simply reframe the use case for the backlog or change the terminology you're using. I recommend that you think of it as a future-work register or project artifact rather than the status of a work item. When you do that, it becomes self-evident that the backlog (whether Product Backlog, Sprint Backlog, or some other form of backlog) is really an incoming stage for applying selection criteria before something becomes a to-do item. In other words, it's the sorting bucket for prioritization and forward-looking product planning rather than a list of what's currently in scope right now.

Since agile frameworks are generally based on pull-queues and incremental, iterative, or just-in-time planning, the backlog is where things are held until they are in scope for a near-term increment or ready to be pulled into the work pipeline. At that time, they would be removed from the backlog and into a Sprint Backlog, To-Do column on a kanban, or placed into the appropriate work-in-progress bucket representing the current status or pull-queue for the given work item.

Visualizing Backlogs as Part of the Project Hierarchy

Without using the term "backlog" directly (although I've mentioned where certain things fit within Scrum's two backlogs for comparison) you might visualize the purpose and utility of backlogs like this:

• PROJECT (a finite process to develop, build, or deliver something)
  • Planning Artifacts
    • Future Work Items (in Scrum, this is the Product Backlog)
      • Lower-Priority Work Items (in Scrum, these are generally unrefined epics for the more-distant future)
      • Near-Term or Upcoming Work Items (in Scrum, this is the stuff addressed in Backlog Refinement)
      • Immediately In-Scope Work Items (in Scrum, this is the stuff addressed during Sprint Planning)
    • Currently In-Scope Work Items (in Scrum, this is the stuff pulled into the Sprint Backlog from the Product Backlog to meet the current Sprint Goal defined during Sprint Planning)
  • In-Scope Work Items (in Scrum, this is the current Sprint Backlog that meets the Sprint Goal and collectively delivers the Increment)
    • Ready-for-Work Items (the current iteration's pull-queue; often the Sprint Backlog itself, or a To-Do column in Kanban)
    • Work-In-Progress Items (can be represented by multiple states; basically any active status your processes require including Development, QA, Review, or any other activity needed to meet the Definition of Done)
    • Done (in Scrum, this is the stuff that would be demoed or deemed delivered during the Sprint Review; however, in continuous delivery or continuous deployment environments it may actually already have been "delivered" if required by the Definition of Done)

In agile frameworks, backlogs are planning artifacts, while statuses are applied to work-in-progress items. The top-level item is the project, not a backlog, and there can be multiple backlogs to represent pull-queues for various activities.

Answer 8

One dimensional backlogs are a thing of a past I would say. At least 2 dimensions are used in well structured backlogs, in some cases even more. Dimensions:

• Priority
• Time frame
• Logical group
• Readiness / Status

But again, there is fine line between good backlog and complicated pile of work items.

An example of such backlog both in Kanban and list approach can be found in this live Teamhood board.

Answer 9

A project backlog is a prioritized and structured list of deliverables that are a part of the scope of a project. It is often a complete list that breaks down work that needs to be completed.

The project backlog helps structure scope and identify business priorities before teams spend too much time planning the details.

For longer projects, teams may not keep the entire work breakdown structure in the project backlog. Instead, it may only focus on what needs to be done during a specific time period.

Product Backlog The product backlog is used by organizations to plan work for enhancing their product. Typically, organizations that aim to be Agile have abandoned projects altogether and the product backlog is the artifact that defines scope. This backlog is a container for work that you want to do to remain competitive. The product owner works in collaboration with other stakeholders (customers, teams, and analysts). Items are then added or removed, allowing it to change frequently.

Sprint Backlog A sprint backlog is a subset of deliverable items that usually form a product or project backlog. It contains all work items the team has committed to completing within a current sprint (which may also be items from outside the product backlog). All of these items should be finished during the time-specific sprint. It is important that your sprint backlog aligns with your overall sprint goal.

Project Backlog Project backlogs contain ideas that focus on a specific project. These backlogs are usually handled by a project owner in charge of a single team. Projects can be part of larger products managed by a product backlog. For example, an organization may deliver customer implementation projects as part of a larger product backlog.