“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.
- ID: Unique identifier for the specific PBI
- Name: A short name describing the specific PBI
- Description: A detailed description describing the specific PBI
- Date Needed: The date a specific PBI needs to be completed
- Priority: A number representing the relative priority to other PBIs
- Functional Area: The category of a functional area of the product
- Release ID: Targeted release ID for the product
- Estimate: The estimated size of effort in story points
- Acceptance Criteria: Conditions needed to be met for the PBI to be considered complete
- Parent Epic or Story: The Epic or User Story ID the specific PBI is related to
- Dependent PBI: The PBI that must be completed before this PBI can start (e.g., enablers)
- Team Name: The name of the team working on the specific PBI
- Iteration ID: The iteration ID the work will be completed (e.g., Sprint ID in Scrum)
- Status: The status of a specific item: Not-Started; In-Progress; Done
- Blocked Indicator: An indicator that the specific PBI is blocked requiring immediate action
- Date Started: The date the specific item was started
- Date Completed: The date the specific item was completed
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:
- Product Burndown and Burn-Up Charts
- Blocker Charts
- Iteration Burndown Charts
- In-Progress PBI Charts
- Completed PBI Charts
- Upcoming (next iteration) PBI Charts
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.
Conclusion
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.