The Product Backlog Speaks

“The Backlog Speaks” is a metaphor we use to get product development lifecycle information. At Bellese, the backlog is at the heart of our product development initiatives. We’ve found that having a transparent and well-groomed backlog that speaks to the team’s and stakeholders’ needs saves critical time.

Who Uses the Backlog?

A product backlog is a journal of activities to fulfill product development goals. At Bellese we define product backlog items (PBIs) to manage work. We manage our work using agile and lean methods that we call Lean Work Management (LWM). Work items include performing user research and design activities, developing APIs, and any other type of work required to meet product goals.

It is important to identify who will be using your backlog and what information is valuable to them. Users of your product, product owners, stakeholders, team members, delivery managers, and anyone that has an interest in the activities and outcomes of your product are potential users. Understand these users’ needs and determine what they want to hear throughout your product’s journey. The backlog should include information to support the planning, development, release, and maintenance of your product.

What Do Your Backlog Users Want to Hear?

First, identify the information each type of user needs. Product users will want to know when specific features will be available. Identify what information is important to manage your team’s work. Also, determine the information your stakeholders will need to understand the plans and status of your product development activities. The backlog should provide answers to frequently asked questions. For example, when will a feature be available in Beta? what team will deliver an architecture enabler for other teams?

What Specific Metadata is Essential?

Once you have identified what you and other stakeholders want to hear from the backlog, define the essential metadata required to capture this information. Over the past fifteen years, we’ve worked on various sized product development initiatives that have surfaced meaningful attributes that we’ve outlined below.

Essential metadata are attributes we’ve used on projects with two or more teams, regardless of work management method, such as SAFe, Kanban or Scrum. You may require additional metadata to support your specific work management method (e.g., Program Increment for SAFe).

Backlog Grooming/Refinement

Update the backlog as new information is available. This includes priority, acceptance criteria, date needed or other attributes. For example, as soon as new work is identified, a product backlog item (PBI) should be created with at least an ID, Name and brief Description. If team consensus or input is needed, then it is important to meet as a team as soon as the required input is available (e.g., Acceptance Criteria is defined and available for the team to provide an Estimate). Some teams meet weekly to groom their backlogs, others meet as needed. Always update the backlog as soon as a PBI is completed with the Status and Date Completed. Stale backlogs do not speak clearly.

Listen to the Backlog

Teams and stakeholders should listen to the backlog. Consider establishing real-time information radiators that provide transparency into specific aspects of the backlog. We’ve setup information radiators for product users, teams and stakeholders to pull in, such as information from our lean work management tool called RPM, or pushed it to them via real-time chat message (e.g., slack or hipchat), email and on large TVs located in work areas. The information radiators represent a real-time pulse of your project. The following information radiators have proven to be valuable to our teams and stakeholders:

It is important to actively listen to your product’s backlog. Ensure information is readily available to the users you’ve identified. This keeps your teams and stakeholders informed. Not only does active listening of the product backlog provide information on team activities, it also helps stakeholders manage project risks based on real-time project data. For example, a blocker chart tells you activities that are not moving that require action, and a product burn-up chart tells you if the team’s velocity will keep up with new scope and milestone dates.


The product backlog is the heart for managing work. A healthy backlog provides information transparency and should be readily available to all backlog users. You can achieve this by understanding the information your teams and stakeholders need throughout the lifecycle of the project. It is important to keep this information up to date. A well-groomed backlog keeps your teams and stakeholders informed while building confidence in your work management. A healthy backlog saves you significant time and effort in managing expectations.

Written by