Product Backlog

Avi Siegel

•

5 min read

What is a product backlog?

A product backlog is a dynamic, prioritized list of work items that an Agile team uses to guide product development. It serves as the single source of truth for all actionable tasks related to building, improving, and maintaining a product.

What are key characteristics of a product backlog?

A product backlog should be:

  • Prioritized: Items in the backlog are ordered based on their importance, with the most critical items toward the top.

  • Detailed: Items in the backlog have enough detail in them that they can be acted on. Lower priority items may be less defined, but must be appropriately detailed by the time they may be pulled into a sprint.

  • Continuously refined: The backlog undergoes regular grooming to ensure items in it are appropriately detailed and prioritized. Both the backlog grooming activity and Backlog Grooming ceremony are utilized for this purpose.

  • Actionable: The backlog specifically includes work to be done, such as components of features to build, bugs to fix, and tech debt to address. It specifically does not include non-broken-down epics (which belong on the roadmap), ideas (which belong in an idea tracker), or other tasks that are not, in and of themselves, actionable.

  • Dynamic: The backlog is a living document that is continuously updated over time as product, business, and market conditions necessitate the additional, removal, and reprioritization of work.

What types of tasks go into a product backlog?

All work that is definitively planned to be done (albeit not necessarily on a specific timeline) belongs in the backlog. This includes such tasks as:

  • New feature development

  • Iterations on existing features

  • Bug fixes

  • Support requests

  • Infrastructure improvements

  • Addressing technical debt

  • Writing of tech specs

  • Documentation

  • UI/UX tweaks

The above tasks are typically classified by task types that include:

  • Story: work involving features

  • Bug: user-facing issues in production environments

  • Defect: issues with in-progress features that are not yet available to users

  • Support request: one-off customer needs

  • Infrastructure: keep-the-lights-on projects and technical debt

  • Spike: research, writing tech specs based on research, and other documentation

Pro Tip: Epics purposefully do not appear in the above list. Stories that are aligned to an epic do indeed belong in the backlog. However, the epics themselves are better suited for the roadmap. In this way, the backlog can represent specific actionable tasks, as opposed to broad sets of work that have not yet been broken down into bite-sized pieces.

Note that different teams will choose to employ various task types at varying levels of specificity. For example, a team might not choose to distinguish between user-facing bugs and non-user facing defects, and simply categorize them all as bugs.

Pro Tip: Choose task types based on your strategies and goals. To continue with the above example, a good reason to separate bugs from defects might be if a team targets a 20% time allocation to user-facing bugs, while considering defects a cost of feature development and thus part of a 50% time allocation for feature work. In this example, budgeting decisions can be impacted, so the deeper level of specificity between bugs and defects would be worthwhile.

Who owns the product backlog?

The product manager (PM) is the official owner of the product backlog. As such, it is their responsibility to continuously manage the backlog. Their duties include:

  • Conducting continuous backlog grooming

  • Facilitating recurring Backlog Grooming ceremonies

  • Ensuring enough work exists in the backlog to fill upcoming sprints

  • Vetting and approving new items for inclusion in the backlog

  • Removing items from the backlog that are no longer high enough priority to track

How is the product backlog filled?

The PM owner of the backlog is responsible for adding work to (and removing work from) the backlog. This work should be vetted, prioritized, and actionable.

Pro Tip: It can be tempting to include all work that ever might be done in the product backlog. However, note that this strategy only serves to make backlog management more difficult, due to the sheer amount of work it can hold. So only include work that is likely to be done in the near- or mid- term. Take comfort in the fact that if certain work ends up being more important than you realized, it will come up again, and you can more effectively prioritize it at that time.

Other individuals may create tasks that they recommend be included in the backlog, but those tasks should not immediately be added to the backlog officially until they have been reviewed by the PM. For instance, one-off infrastructure work logged by engineers, as well as one-off support requests logged by customer support, should be approved by the PM before making it to the official product backlog - else the backlog will become an unmanageable and unprioritized mountain of work that will never be done.

Pro Tip: Employ a triage strategy to ensure that the only work that appears in the product backlog is work that has been properly vetted and approved for the backlog. If anyone beyond the backlog owner is allowed to add tasks to it, the backlog can quickly grow out of control. For instance, if the PM, who is responsible for prioritizing tasks, is not even aware that a task made it onto the backlog, then that task will realistically never be prioritized. Similarly, if a logged bug is in fact the system working as intended, then that bug should be archived - but if the PM isn’t aware of the bug, it will take up unnecessary space on the backlog indefinitely.

Best practices for managing a product backlog

  • Utilize a triage view. Keep unapproved work separate from the official product backlog. Only allow the backlog owner to transition work from triage to the official backlog.

  • Continuously refine the backlog. Review the triage list at least once per day. Groom the backlog yourself at least once per week. Host a backlog grooming session with the entire development team once per sprint.

  • Focus on value. Prioritize items that deliver the most value to users and the business.

  • Aim to zero-inbox your product backlog. This does not mean you should have zero items in your backlog, it means you should have zero items in your backlog which require your attention. Non-broken-down epics belong on the roadmap, not the backlog. Unreviewed bugs belong in a triage view, not the backlog. Ideas belong in insight trackers, not the backlog. Unrefined tasks that lack context and details and will never be done anyway minimally belong in the icebox, but really should just be archived. What remains are the tasks that you should prioritize and refine. Stay on top of that shortlist, and you’ll improve your sanity.