Files
magnus919_agent-skills/kanban-guru/references/multi-portfolio.md
Magnus Hedemark 555cf087d9 feat: add kanban-guru skill
A virtual Kanban expert skill with rich reference material covering all
seven cadences, classes of service, Little's Law, flow metrics,
multi-portfolio operating models, and Scrum-to-Kanban transitions.

- SKILL.md: diagnosis, design, and transition modes with QuickScan
- references/cadences.md: all seven cadences with agendas and formats
- references/classes-of-service.md: four canonical + custom classes
- references/flow-metrics.md: SLEs, CFDs, forecasting, right-sizing
- references/multi-portfolio.md: capacity allocations, board design
- references/transition-guide.md: Scrum-to-Kanban playbook
- references/wip-limits.md: Little's Law, calibration, breach signals
- references/glossary.md: A-Z kanban terminology

Sanitized for public use — no private context or references.
2026-05-22 01:16:37 -04:00

4.3 KiB
Raw Permalink Blame History

Multi-Portfolio Kanban Operating Model

When a single engineering team serves multiple product portfolios simultaneously, classic Scrum breaks down — its 1:1:1 assumption (one Product Owner, one team, one backlog) cannot handle the reality of multiple stakeholders with competing priorities. Multi-Portfolio Kanban addresses this structural failure.

Core Insight: Engineering as a Service

Treat the shared engineering group not as a team juggling multiple masters, but as a service with multiple clients. Services have explicit capacity, published service-level expectations, governed intake processes, and regular performance reviews. The clients compete transparently for service capacity under visible, agreed rules.

Capacity Allocations

Leadership sets a baseline capacity split — a percentage of throughput earmarked for each portfolio over a planning horizon (typically a quarter):

Portfolio Allocation Notes
Portfolio A 60% Primary product line
Portfolio B 30% Internal platform
Unallocated buffer 10% Incidents, tech debt, unplanned

These allocations are:

  • Applied at Replenishment when deciding what enters the Ready queue
  • Tracked against actual throughput in Service Delivery Reviews
  • Adjusted through formal channels when priorities shift — not through ad hoc escalation

Capacity allocations eliminate the need for stack ranking portfolios. No PM needs to "win" against another PM. Each portfolio has a guaranteed share.

Board Design

One single board for all portfolios — not one per portfolio. The board is the team's operating reality and must show everything in one place.

Swimlanes (JQL-based in Jira, or equivalent):

  • Expedite lane at top (WIP limit 1) — pinned above all portfolios
  • Portfolio A lane
  • Portfolio B lane
  • Everything Else lane — tech debt, internal work, team improvement

Columns representing actual workflow stages:

  • Backlog (not counted in WIP)
  • Ready (committed, meets Definition of Ready)
  • In Progress (active development — WIP limited)
  • In Review (code review, QA — WIP limited)
  • Done

Card colors by portfolio for at-a-glance allocation visibility during standup.

Cadences for Multi-Portfolio

Replenishment (12×/week, 3060 min): Replaces sprint planning. All PMs attend with the EM/TL. The team selects what enters Ready based on WIP capacity and allocation percentages. All new work enters through Replenishment — no side-channel asks to engineers.

Service Delivery Review (bi-weekly or monthly, 6090 min): The primary governance loop. EM/TL presents metrics by portfolio: throughput vs. allocation, lead time percentiles, blocker frequency, SLE hit rate. PMs formally assert whether their portfolio is under- or over-served. Capacity allocations are adjusted here with data, not politics.

Team Retrospective (every 24 weeks, 60 min): Inward-focused. Engineers surface context-switching burden, expedite frequency, handoff friction, and replenishment quality. PMs do not attend — their concerns belong in the SDR.

Side-Channel Asks: The Most Common Failure Mode

The most common failure in multi-portfolio governance is the direct ask — a PM messages an engineer directly, or a senior leader asks someone to "just squeeze this in." These asks are invisible to the board, consume real capacity, and violate allocations.

The fix: All work enters through Replenishment. The EM/TL tells engineers: "If anyone asks you to work on something not on the board, the answer is 'please bring it to Replenishment.'" PMs are told: "I will route any direct asks back to you for submission through Replenishment."

Role Shifts

EM/TL moves from "sprint runner" to "service owner for flow" — accountable for the Kanban system design, enforcing WIP and policies, blocking side doors, and providing range-based forecasts.

PM moves from owning a dedicated squad to competing transparently for shared capacity. Their preparation discipline matters more: small, well-defined, high-value candidates are selected first. The primary governance lever is the Service Delivery Review, not the sprint negotiation.

CTO/CPO sets baseline allocation splits, reviews systemic bottlenecks in Risk Reviews, and resolves allocation disputes that can't be resolved at the team level.