What it is and why it matters
This domain is tested only in the KGFP, the level of advanced skills, analysis and improvement of Kanban systems. It deals with what happens when a well-managed team still delivers late, because value for the customer depends on other teams, on shared services and on decisions made at other levels of the organization.
It is common to see teams with well-designed boards, respected WIP limits and stable cycle time, while an initiative that passes through four of those teams takes months. Each part is optimized; the whole is not. The end-to-end flow is where the customer lives, and that is where most of the time is lost: in waits between teams, in dependencies discovered late and in portfolios with too many initiatives started at the same time.
Key concepts
Dependencies between teams and services
A dependency exists when an item cannot move forward without something that another team or service delivers. It adds waiting and variability, and each dependency multiplies the risk: if three teams need to deliver their part and each has an 85% chance of meeting the deadline, the chance that all three meet it, with independent deliveries, drops to about 61%.
There are three responses, in order of preference:
- Eliminate the dependency, by changing team composition, architecture or how the work is split, when that is feasible.
- Reduce the impact, by bringing discovery forward: identify dependencies before the commitment point, not in the middle of the work.
- Manage what remains, with explicit visualization, service policies between services and tracking of the age of items waiting on another team.
In the visualization, each dependency appears on the card of the waiting item and, preferably, on the board of whoever needs to respond. Practice this reasoning in the dependencies under control challenge.
Shared services
An infrastructure, security or data team serves several others. In practice, it is a service with internal customers, and it deserves to be managed as one: with classes of service, its own SLE, a Service Delivery Review with the customer teams and an agreed capacity allocation. Without this, each internal customer treats its own request as urgent, and the shared service becomes the bottleneck of the whole organization.
Multi-level Kanban
Organizations apply Kanban at different levels, each with its own work item and its own pace:
- Team: items such as stories, tasks or tickets, with cycle time in days.
- Service or coordination: features or deliveries that cross several teams, with times in weeks.
- Portfolio: initiatives, projects or strategic bets, with times in months.
The Flight Levels approach, by Klaus Leopold, popularized this view of levels. The central point is that a higher level does not replace the lower ones; it coordinates what the lower levels cannot coordinate on their own. The most important WIP limit in the organization is usually the portfolio one: the number of initiatives in progress at the same time. When it is high, every team works on everything, and nothing finishes.
End-to-end visibility
Seeing the end-to-end flow means following the item from the customer’s request to the value delivered, across teams. In practice, this means:
- a higher-level board where each card is a delivery to the customer, not a task for one team;
- a link between the higher-level card and the items on the team boards;
- measuring end-to-end lead time, in addition to each team’s cycle time;
- recording the waiting time between teams, which is usually invisible on individual boards.
When this view exists, the conversation changes. Instead of asking why the payments team was late, the Operations Review asks why deliveries wait, on average, 9 days between the end of development and the start of user acceptance testing.
Portfolio-level forecasting
The same probabilistic techniques from domain 4 apply to whole initiatives, with extra care. A practical way to forecast when an initiative will finish is:
- estimate the number of items as a range, for example 30 to 45, instead of a single number;
- use the historical throughput of the level that delivers those items;
- consider how much of the team’s capacity is allocated to the initiative, since it is rarely 100%;
- run the Monte Carlo simulation and give the date at the chosen percentile.
The forecast improves when portfolio WIP is low, because each initiative gets a larger and more stable share of capacity. Redo the forecast every cycle: as the initiative moves forward, the range of items narrows and the date becomes more reliable. Use the Monte Carlo simulator with real data from the flow analyzer.
Common mistakes
- Adding up team estimates to get the initiative’s date. It ignores waits between teams and variability.
- Creating a portfolio level that only controls. If it does not limit the WIP of initiatives, it does not improve flow.
- Treating the shared service as an external supplier. It needs joint policies and reviews.
- Discovering dependencies in the middle of the work. The analysis should happen before the commitment point.
- Comparing throughput across teams. Items have different sizes and natures; the comparison encourages distortions.
How this shows up on the exam
In the KGFP, questions in this domain start from scenarios with several teams and data. Examples of the kind of decision: which change reduces end-to-end lead time when the waits are between teams; how to set the portfolio WIP limit; which forecast to give for an initiative considering the allocated capacity and the range of items; how to handle a shared service that is the bottleneck for several teams. The KGFP practical case also uses per-candidate data to test this reading.
Frequently asked questions
Is this domain on the KGCP exam?
No. Domain 8 is tested only in the KGFP. For KG Foundations and the KGCP, the tested domains are 1 to 7. Knowing this content helps you understand your team’s context, but it is not required on the exam.
How do I deal with dependencies that cannot be eliminated?
Make them visible on both boards involved, agree on service policies between the services and track the age of the waiting items. Discuss the patterns in the Operations Review, where the people with authority to change the design across teams are.
Can I forecast an initiative that has not been broken down yet?
Yes, with a range. Estimate the number of items as an interval, use historical throughput and the allocated capacity, and simulate. The initial forecast is wide and narrows as the initiative is broken down and the first items are delivered.
