Executing-unit baseline
Which ARTs, suppliers, platforms, departments and shared services carry capacity?
Exercise 1D
Estimate Capacity Buckets
Make the capacity reality of the Value Stream visible: which executing units carry work, which bucket classes are useful, where historical data can come from, and how capacity was roughly spent in the recent past.
What we produce
A rough but useful capacity baseline.
The output is good enough when participants can explain how much capacity exists in the executing units — and which capacity is realistically available for new Value Stream objectives after fixed work, KTLO, maintenance, compliance and enablers are visible.
Bucket model
Which capacity classes make trade-offs visible in this Value Stream?
Historical data path
Who or what system can provide data or credible estimates by bucket?
Capacity distribution
A rough 100% view per executing unit: how capacity was spent recently.
Why this exercise matters
Demand normally exceeds capacity. That is the point.
Business objectives and Value Stream Initiatives usually ask for more than the system can deliver. Capacity visibility does not solve the trade-off. It makes the trade-off discussable.
Business demand
Objectives and initiatives usually exceed available capacity. That is normal.
Hidden fixed work
KTLO, maintenance, incidents, compliance and supplier work silently consume capacity.
Enabler reality
Architecture, platform, tooling and automation compete with feature delivery.
Trade-off quality
A roadmap is useful only when the room can see what must be deferred, split or stopped.
Coordination focus
Capacity hotspots show where Value Stream coordination must start first.
Preparation input
Historical capacity data helps the conference avoid optimistic negotiation theater.
Core question
How much capacity is really available for new Value Stream objectives after everything else is made visible?
Exercise structure
Four abstraction levels. Start simple.
Do not turn the exercise into a data-science project. Count people first, choose buckets second, identify data sources third, and only then sketch rough percentage splits.
Count people
How many people and teams exist in each executing unit?
Choose buckets
Which capacity classes are meaningful in this Value Stream?
Find data sources
Who can provide historical data or credible estimates?
Estimate split
How was capacity roughly distributed across buckets?
Principle
Use rough estimates, not false precision.
The goal is directionally useful transparency, not accounting-grade reporting. Ranges, rounded percentages and visible uncertainty are better than precise numbers built on fuzzy categories.
A useful first 100% split
Start with a recent PI, quarter or release period. If the split creates a better question, it has done its job.
Canvas 01
Executing Unit Capacity Baseline
One row per executing unit. People counts are enough for the first pass. The most important fields are unit, availability, major fixed work, known constraints and data owner.
| Executing unit | Type | People | Teams | Dedicated to VS? | Major fixed work | Known constraints | Notes / source |
|---|---|---|---|---|---|---|---|
| ART A | ART | 95–110 | 9 | mostly | current PI commitments | test bottleneck | RTE estimate |
| Supplier X | Supplier | 35–45 | 3 | partial | contracted milestones | lead time | ask supplier PM |
| Dept. Y | Traditional | 20–30 | — | partial | project portfolio | manager approval | range only |
Use ranges when unsure
Capture partial availability
Write source / owner
Do not chase exactness now
Canvas 02
Capacity Bucket Selection
Buckets should make trade-offs visible. Keep the smallest set that people can estimate quickly and consistently.
| Bucket candidate | Use | Maybe | Not useful | Definition for us | Typical examples |
|---|---|---|---|---|---|
| Features / New Initiatives | □ | □ | □ | new business capabilities, differentiating work | |
| Enablers | □ | □ | □ | architecture, automation, infrastructure, org enablers | |
| Maintenance | □ | □ | □ | defects, lifecycle work, refactoring, tech debt | |
| Keep the Lights On | □ | □ | □ | operations, incidents, support, service continuity | |
| Compliance / Safety | □ | □ | □ | regulatory work, safety cases, audits, evidence | |
| Innovation / Learning | □ | □ | □ | spikes, prototypes, AI experiments, discovery | |
| Unplanned Buffer | □ | □ | □ | risk reserve, supplier surprises, escalation capacity | |
| Own: __________ | □ | □ | □ | context-specific bucket |
Rule of thumb
If the group cannot explain how the bucket changes a decision, merge it or remove it.
Snippet cards
Choose the smallest capacity model that reveals real trade-offs.
Use the cards as prompts. Stop after six to eight buckets in a fast workshop. Add additional buckets only when a hidden capacity load would otherwise disappear.
Core buckets
- Features / New Initiatives
- Enablers
- Maintenance
- KTLO / Operations
- Compliance / Safety
- Innovation / Learning
- Unplanned Buffer
Additional candidates
- Integration / Test
- Platform / Shared Services
- Supplier Coordination
- Production / Launch
- Customer Support
- Transformation Work
- Portfolio / Governance
Good bucket test
- Small enough to estimate
- Different enough to matter
- Measurable enough to reconstruct
- Relevant enough to change a roadmap choice
Anti-patterns
- Too many tiny categories
- Categories nobody can estimate
- Hidden KTLO or incident work
- Enablers treated as “free”
- Precision theater with fuzzy data
Canvas 03
Historical Data Source Checklist
Before filling a capacity split, decide where credible data or estimates can come from. If one source is weak, triangulate two or three signals and make confidence visible.
| Source | What to ask / inspect | Can map to buckets? | Confidence | Owner / follow-up |
|---|---|---|---|---|
| RTE / STE | PI capacity, train commitments, impediments, unplanned work | □ | H / M / L | |
| Product Management | feature work, scope changes, objective load | □ | H / M / L | |
| System / Enterprise Architect | enabler demand, architecture runway, integration work | □ | H / M / L | |
| Department / Supplier Lead | people availability, project load, lead times | □ | H / M / L | |
| ALM / Jira / ADO | work item history, labels, epics, features, defects | □ | H / M / L | |
| Incident / Support System | operations, support, field issues, KTLO load | □ | H / M / L | |
| Finance / Controlling | budget, cost centers, capitalization, actuals | □ | H / M / L | |
| Compliance / Risk Register | audit work, evidence creation, regulatory gates | □ | H / M / L | |
| Release / Program Calendar | release windows, milestones, launch effort | □ | H / M / L |
Canvas 04
Capacity Distribution Canvas
Create a 100% split per executing unit for a recent PI, quarter or release period. The numbers can be ranges, but the assumptions must be visible.
| Unit | Period | New | Enablers | Maintenance | KTLO | Compliance | Innovation | Buffer | Source / confidence |
|---|---|---|---|---|---|---|---|---|---|
| ART A | last PI | 32% | 18% | 16% | 19% | 8% | 3% | 4% | RTE estimate / M |
Data quality rule
Known, estimated and unknown are all usable states. Unknowns become follow-up work instead of blocking the exercise.
Debrief
Turn capacity into conference-preparation input.
Close with an honest statement about how much capacity exists, where fixed work dominates, where the data is weak and which units need follow-up before the first Value Stream Conference.
Baseline
Which executing units and people counts are visible?
Buckets
Which capacity classes will we use for the first trade-off conversation?
Data owners
Who can provide or validate historical capacity information?
Hotspots
Where is new work constrained by KTLO, maintenance, compliance or enablers?
Unknowns
Which assumptions must be validated before conference preparation?
Good enough means honest
Capacity visibility is a shared decision aid.
The Value Stream Conference should not use capacity data to punish realistic numbers. It should use it to make roadmap trade-offs credible.