Delivery At Scale 3: Managing the Product Backlog at Scale

Summary

• At scale, the definitions of the Product Goal and Product Backlog at scale are unchanged: the Product Goal serves as a target for the Delivery Teams to plan against, the Product Backlog is an ordered list of everything needed to meet the Product Goal.
• The Product Backlog should be stack-ranked by relative business value.
• At scale, the Product Backlog must be structured so it can be serviced by multiple delivery teams.
• The Product Owner role does not scale beyond a couple of teams, hence management of large backlogs needs alternative Product Ownership arrangements.
• A Kanban system is an effective way to manage the Product Backlog intake process.

Creating The Product Backlog

In many organizations Product Backlog construction is often managed in an ad hoc manner. This can result in lack of clarity on what is needed to be built, or lack of clarity on priorities. This not only slows down the delivery system impacting overall lead and cycle times, but may also cause significant misses in bringing important business value to market. We want to evolve the backlog intake process to where it operates as a system, with a defined workflow. The workflow includes taking in requests for new product capabilities, analysis of those items to ensure Product Goal alignment, refinement, estimation and ranking. The output of this process is a ready and prioritized backlog of work items for the delivery system.

The most important objectives for the Product Backlog are:

• Ensure backlog items are solidly aligned with business goals and strategy.
• Define each backlog item with sufficient clarity that it is amenable to planning and estimation by a development team.
• Estimate the size of resulting backlog items so that required delivery capacity is understood.
• Build out the backlog to a depth that matches the production capacity of the development system.
• Prioritize the backlog to ensure that items of the highest business value are always next to be developed.

Business Strategy Alignment.

The initial filter for incoming requests is to ensure alignment with the Product Goal. Any proposed new capability or feature must help further the advance towards the Product Goal. An example for our eCommerce business might be a request to provide high quality product images with search results. Why? Because this can make it easier (faster with less perceived risk) for shoppers to make a purchase decision. Which leads to the business outcome of increased sales, and advances progress towards a vision of being the leading online supplier of a specific product. Further, the impact of implementing such a feature would be measurable via a Key Performance Indicator (KPI) like Conversion Rate.  Making the desired business outcomes, value drivers, and KPIs explicit, forces a high level of clarity about the business value of any proposed feature, and helps delivery teams be really clear about what they need to accomplish.

Getting The Backlog Ready

Items on a Product Backlog which are the source of work for multiple feature delivery teams most likely begin life as coarse-grained placeholders for further elaboration and refinement. Then, in a process of collaboration between the backlog owner and the delivery teams, these are refined into enough detail where responsibility for planning and delivery can be assumed by the feature teams. The orchestration of the required workflow at this level can be effectively managed by a Kanban System.

Just as we have a definition of ready at the user story level to define the level of detail a team needs to support sprint planning, so also a feature definition of ready is useful to identify the appropriate level of detail needed to support development planning and execution. A feature definition of ready could be reflected in a template along the following lines:

Feature	High Quality Product Images
Description	Provide high resolution product images from multiple perspectives
Benefits	Good quality images are a key determinant to move products on eCommerce websites and increase conversion rates and sales.
Acceptance Criteria	Image resolution at least 300 pixels per inch Multiple images showing the various perspectives of the item such as front, side, underneath, Image size of either 640×640 or 800×800 pixels, but use consistent size for all images Ability to zoom in on a specific piece of the object and to capture only one detail of the whole photographed product. Change product image on hover which allows customers to view another image of product by just hovering Thumbnails also provided of 200×200 pixels
Value Driver	Increase revenue per visitor
KPI	Conversion Rate
Business Outcome	Revenue growth

We can see that having good feature acceptance criteria helps development teams better understand the full scope of required functionality, and also serves as a good starting point for user story mapping.

Feature Estimates

Having an initial estimate for a feature not only provides an idea of needed development capacity, but also helps with relative ranking and development sequencing. At this point we only need a course-grained estimate, say, how many sprints will it take to build a feature, or S/M/L sizing (which could then be calibrated in sprints. For example S/M/L could be 1/3/5 sprints). If a higher level of confidence is needed, we could do an initial story-mapping using the list of feature acceptance criteria as a starting point. We could also factor in overall technical complexity and dependencies to round out the estimate. Save the resulting estimate in the feature template for later reference.

Feature Ranking and Sequencing

Product backlogs should be stack-ranked – not simply prioritized. This is all about realizing the highest value at the earliest opportunity, and minimizing work in progress.  Many product owners and their teams simply prioritize features as High, Medium, or Low priority. Inevitably, we frequently end up with multiple high priority features, which offers little guidance on delivery sequencing. This results in teams having multiple backlog items in progress at the same time which delays getting any individual feature to done. This severely limits the flexibility of teams to make mid-flight changes. Further, it also delays getting feedback from users and stakeholders on finished work, which impedes the ability to iterate, adapt and continuously innovate. Limiting WIP by having an objectively ranked and sequenced backlog is the key to optimal delivery lead times.

By adopting the practice of stack-ranking (or, rank-ordering) of the product backlog, the team has total clarity about which item they should be working on. When work on the highest ranked item is done, the team moves to the next item on the list. When things change, resulting in re-ranking items or even adding new ones, that is not a problem because the team can finish the current item and now has the flexibility to start working on something else, no matter how new or old it is.

Feature ranking is done on a relative basis against other features in the backlog. For this we can use a technique like Weighted Shortest Job First (WSJF) or some variation. WSJF is basically a scheduling algorithm that strives to ensure features of highest value and lowest cost (lowest consumption of development capacity) are ranked highest for delivery.

 

The basic rationale for WSJF is 2-fold:

1.  Prioritize work that has the highest cost of delay or highest overall value in terms of business value, time criticality and risk reduction.
2. When all jobs have the same delay cost, or same overall value, do the one with least effort first (The fastest way to realize value).

Intake Workflow

A good way to orchestrate the intake process is to use a simple Kanban system and run a cadenced intake event where an intake team can conduct analysis and refinement to get features to a state of readiness.  This elevates the process into something beyond the ad hoc, and provides a significantly more systematic approach. The intake team will comprise both business and technology representatives. Here is an example:

Basic workflow states are:

Funnel. Initial state of all feature requests. Features in this state should at least be reviewed for alignment with with overall Product Vision, business strategy and the Product Goal. Features may be accepted for further analysis or rejected at this stage.

Business Analysis. The next step should be to elaborate the basic feature description and acceptance criteria. Acceptance criteria will help clarify intended functionality and place a boundary on overall scope. At this stage we should also articulate how the feature contributes to business goals and strategy. If we have conducted a value driver exercise, this would be the appropriate time to review that information and to confirm alignment.

Technical Analysis. Once the fundamental requirements and business elements have been analyzed we need to review technology-related aspects of the feature and their potential implications for development, such as non-functional requirements, architectural runway or enabler needs, and any technology-related dependencies needed to support construction of the feature. All of these considerations should be factored into the initial sizing of the feature.

Ready. Features that have been processed through initial intake filter, and have completed business and technical analysis are considered ready for development. At this point features should be sufficiently understood to support User Story mapping and development planning. We should strive to have enough ready features in the backlog to meet the near-term needs of the delivery system, but not too many as to create the unnecessary overhead associated with having to maintain a large backlog.

As we progressively refine features from the point of intake to where they are ready for implementation, we are building out a well-defined backlog. At this point features will be stack-ranked in the order we want them delivered based on business value, and each feature will have at least a rough cut estimate in story points. At a macro level we should have a view of whether we have sufficient development capacity to meet the demand reflected in the backlog. This data can also support capacity planning at a portfolio level.

Intake of Product Backlog items and their subsequent delivery are not intended to be sequential process steps, but rather 2 concurrently operating sets of processes. The workflow for Product Backlog construction is follows:

 

Scaling The Product Owner

A single Product Owner simply does not have the bandwidth to support more than a couple of development teams. For Value Streams operating at a scale beyond this we need a way to scale the Product Owner. One way is to separate the responsibilities into 2 categories: those that are primarily market-facing, and those that are mostly team-facing. This is the so-called Product Manager/Product Owner Model. A single Chief Product Owner (or Product Manager) is responsible for the overall Product Vision, Product Goal and Product Backlog. Each team has a dedicated Product Owner who will support the team in the refinement and prioritization of features into sprint-sized slices of functionality that can be delivered incrementally.

Chief Product Owner: Market-Facing	Product Owner:           Team-Facing
Owns Product Vision & Product Goal Manages Product Backlog Manages feature intake and feature refinement Accepts features as complete Determines product releases	Understands Product Vision and Strategy Manages team product backlog Clarifies customer needs for development team Leads feature decomposition into stories Leads story refinement Manages team backlog and story prioritization Accepts stories as Done

Intake Flow Optimization

The goal of any Product Owner should be to get valuable features into the hands of users as quickly as possible. The metric we use to measure end-to-end delivery performance is Lead Time: The time between the initial feature request to the time the feature is delivered to production. This is the one metric that should be tackled relentlessly. The ability to innovate (create more customer value) and improve (do it faster with higher quality) leads directly to increases in revenues and improved margins.

The intake team must be focused on continuous improvement, guided by some basic principles and helped by the use of metrics. The key metrics of interest will be Lead Time – how long it takes from initial intake of a feature request to delivery to production, and also Cycle Time – the time from initial feature intake to the ready state on the product backlog.

Look at every process through the lens of Lead Time. Lead Time and Intake Cycle Time are key metrics for the intake process. These should be measured on an ongoing basis and opportunities for improvement identified and implemented. Improvements are likely to involve not only reducing waste, handoffs and delays, but also any organizational barriers that are impeding the flow of work to the product backlog.