Enterprise Backlog

Play Description

Also Known As/Similar To

Results Backlog, Enterprise Product Backlog, Product Backlog

Pattern Groups

Scaling Product Ownership, Scaling Strategy

Challenge Categories

Aligning execution with strategy, aligning work across teams

Challenges Addressed

Often, it is difficult to ensure that the work performed by separate, independent teams contributes to achieving an organization’s strategic goals. By having an enterprise backlog shared by many teams, it is easier to ensure that strategic goals and strategic initiatives (Epics) are achieved because they are retrieving backlog items (work) from a common source.

Definition

An Enterprise Backlog is a master list that contains all of the work across all of the products in an organization’s portfolio of products. Locating all of the backlog items in once place makes it easier to coordinate work across multiple products in a large solution, value stream or portfolio. As long as the Enterprise Backlog is well maintained, this makes refinement and distribution of the work on the backlog easier, which makes scaling easier and more effective.

Enterprise Backlogs can typically be organized or in multiple ways in order to support use by specific teams or individuals in the organization. One organizing technique divides the work by size (such as Epics, Capabilities, Features and Stories) so that viewers can either look at larger, more strategic work or smaller, more tactical work. Another organizing technique groups work in the Enterprise backlog that achieves specific strategic objectives (OKRs) of the organization.

Once grouped or categorized, backlog filtering techniques can make it possible to see the work for only a single product, for a single goal, for a single team, or for a single network of teams.

In Frameworks

In LeSS, a product is defined from the user’s perspective and as broadly as possible. This means that something perceived as a “product” from the company’s internal perspective will be a part (sub-product) of the real product in LeSS. Consequently, the Product Backlog functions much like an Enterprise Backlog that consists of items related to different parts of the Product. Requirements Areas are defined when the teams can’t handle the whole product (LeSS Requirements Areas) to form an Area Product Backlog containing many different Requirements Areas (LeSS Area Product Backlog). The Requirements Areas are customer-centric, not component groups, and often a Requirements Area will be limited to several whole-product components.

In Scrum@Scale, an enterprise backlog contains both strategic and tactical work that could span multiple products (Registered Scrum@Scale Practitioner training). Scrum@Scale is not specific about whether the enterprise backlog spans a portfolio of products, a value stream, or just one product and leaves this decision to the organization. (The Scrum@Scale Guide does not explicitly mention “enterprise backlog”, but Registered Scrum@Scale Practitioner training does.)

In SAFe, the structure of the enterprise backlog is more strictly defined. Backlog items are decomposed into Epics, Capabilities, Features and Stories (SAFe Enterprise Backlog). An Epic is defined and refined by Lean Portfolio Management, then handed off to either a Solution Train to divide into Capabilities; or handed off to an Agile Release Train to divide it into Features. Features, which included a benefits hypothesis and acceptance criteria, are handed to individual agile teams to divide into stories small enough to be completed in a single iteration or Sprint.

In the Product Operating Model (Product Operating System), leaders are tasked with setting the strategic direction by identifying and articulating the key problems that need to be solved and defining the desired outcomes for the product. This is typically achieved using Objectives and Key Results (OKRs), which help ensure that goals are centered around achieving meaningful outcomes rather than merely completing tasks or building features. The responsibility for translating these outcomes into actionable features and detailed stories falls to agile teams. Features and stories should be considered hypothesizes and will likely evolve as the team learn more via discovery and obtained feedback during iterative development.

How To Use It:

Like most patterns, there are many ways to use it. A few different implementation approaches to creating an Enterprise Backlog are described here:

• Impact Mapping. Using Impact mapping, one can start with a strategic goal and identify the most likely work necessary to achieve the goal. Per Gojko Adzic, only the work items necessary to achieve the goal are actually delivered.
• Epic-Feature-Story. Per Charlene Cuenca, this approach starts with strategic work and divides it into progressively smaller items until work is small enough to be completed in an iteration.
  • Refine a Strategic Initiative or Epic. While refining it, identify work that might be implemented in each product within a portfolio of products. Those items are likely to become features.
  • Refine Features. Each feature should create or enhance a product or solution, but be too large to complete within an iteration by a single team. As a result, these should be handed to teams and subdivided into stories.
  • Refine Stories. Clarify them and prioritize them for a single team to implement during an iteration.
• Value Stream Development. By identifying and mapping one or more value streams in an organization, one can identify the work necessary to build and maintain the value stream. The work identified will make up items on the Enterprise Backlog.
• User Story Mapping.  User Story Mapping can be used to break up larger Enterprise Backlog Items into smaller items that can be developed by individual teams (User Story Mapping).

Irrespective of technique, one should track progress to confirm organizational goals are being achieved. In short, focus on outcomes and results — not on outputs or total work volume.

Tags/Keywords

Enterprise backlog, enterprise product backlog, results backlog