Kanban is like the milkman. Mom didn’t give the milkman a schedule. Mom didn’t use MRP. She simply put the empties on the front steps and the milkman replenished them. That is the essence of a pull system.

– Ernie Smith, Lean Event Facilitator

Portfolio Kanban Abstract

The Framework suggests the development and implementation of Kanban systems for business and architectural portfolio epics. While these kanban systems operate in a similar manner, (and indeed can be implemented in a single system) they are described as separate systems for a number of reasons:

Business epics are typically under the auspices of business unit managers, portfolio, product line, product managers and business analysts
Architectural epics are typically under the auspices of the CTO/technology office, which includes enterprise and system architects.

This Framework page summarizes the implementation and use of the kanban system for business epics. The architectural epic portfolio kanban system is described elsewhere.

Implementing an effective business epic kanban system is typically under the auspices of the Portfolio Management Team. Implementing one requires some basic understanding of lean, agile development, and the productive capacity (velocity available for new development) of all the release trains. But the mechanisms behind kanban are themselves fairly straightforward, and they can initially be simply superimposed on the enterprises existing process. They will tend to naturally evolve quickly thereafter. We recommend the implementation of such a system as it brings visibility to upcoming work as well as work in process, helps facilitate product development flow and can be a key factor in achieving enterprise—as opposed to team or program—agility, and thereby more fully optimize business outcomes.

Details

Motivation for a Kanban System for Business Epics

The kanban system is applied in this context for a number of reasons:

Make the strategic business initiative backlog (upcoming business epics) fully visible
Bring structure to the analysis and decision making that moves these initiatives into implementation, and make that process visible to all
Provide WIP limits to ensure the teams responsible for analysis do so responsibly, and do not create expectations for implementation or timeframes that far exceed capacity and reality
Help drive collaboration amongst the key stakeholders in the business, Architecture and Development Teams
Provide a quantitative, transparent basis for economic decision-making for these, the most important business decisions.

A Prototypical Kanban System for Business Epics

In Agile Software Requirements ([1],Chapter 21), we described such a kanban system as depicted in Figure 1.

Figure 1. Business Epic Portfolio Kanban System

This portfolio kanban system describes four queues that an Epic passes through on the way to implementation (or rejection):

Funnel–the capture state, where all new business ideas are welcome
Backlog–where preliminary estimates of opportunity, effort and cost of delay are established
Analysis–where the more thorough work is done to establish viability, measurable benefit, development and deployment impact, and potential availability of resources. Development of a lightweight business case for consideration.
Implementation– where epics that are selected are allocated to the Release Trains that have with the resources and skills necessary for implementation.

Description of the System

1. The Funnel – Opportunity Identification:

The Funnel queue is the “capture” queue, where all new “big business ideas” are welcome. They can come from any source, but typical drivers for these larger initiatives include:

Portfolio Vision. Most of these initiatives are driven by the enterprises Portfolio Vision and planning process
Unanticipated changes in the marketplace, business acquisitions, mergers, emergence of new competitors, etc.
The need for substantive cost savings or operational efficiencies
Problems with existing solutions that hinder business performance

In this queue, epics need no business case or estimates. Since the investment of effort of items in this queue is minor, this queue is not WIP-limited. All ideas are captured for consideration. Funnel epics are discussed on a periodic cadence established by the Portfolio Management team. Epics that meet the decision criteria are promoted to the Backlog queue.

2. Backlog

Epics that reach the backlog queue warrant further investment of time. In this queue, epics are roughly sized and some estimate of value is established. Time investment is controlled to the discussion level, and perhaps some very preliminary investigation. The epic may be elaborated in the Epic Value Statement format.

Since the investment is increasing, this queue is WIP-limited to limit the number of active items in process. Backlog epics are discussed periodically. Sources of business benefit are identified and items are assigned a Cost of Delay (CoD). Epics that rise to the top of the queue are pulled into Analysis as soon as space is available.

3. Analysis

Epics that make it to this queue deserve a more rigorous analysis, and require further investment. A business analyst is typically assigned as the epic owner. An active collaboration with Enterprise Architects, System Architects, Product Management and key stakeholders on the potentially affected Agile Release Trains is initiated. Solution, design and implementation alternatives are explored. Options for internal development and/or outsourcing are considered. A lightweight business case, with a go or no-go recommendation, is developed.

Items in this queue use scarce resources, and more importantly, imply a substantial upcoming investment, so this queue is WIP-limited based on capacity of the business analysts and enterprise architects, and the desired throughput rates for items in this queue. Promotion from Analysis to Implementation is an important economic decision for the enterprise that can be made only by the appropriate authority, based on the developed business case. Epics that meet the go criteria are promoted to Implementation.

4. Implementation

In this queue, the primary responsibility for the epic is passed to the Programs. Business analyst resources remain available on a “pull” basis: the responsibility for implementation rests with the development teams, but the analyst assists the teams and shares responsibility until the teams have achieved a sufficient understanding of the work required.

This queue is strictly WIP-limited, based primarily on the capacity of the development trains and the solution investment that is required.

Learn More

A more detailed description of this particular system can be found here:

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

A thorough and contemporary view of kanban systems in general can be found here:

Anderson, David. KANBAN. Blue Hole Press, 2010.

Last update: 1 May, 2013