2A · Portfolio
Strategic intent, funding, guardrails and epic roadmaps.
Exercise 2C
Executing Unit Contributions
Decide which ARTs, Solution Trains, Solution Areas, Agile Teams and non-agile execution units must represent capacity, feasibility and constraints in the Value Stream Conference.
Chapter 2 · Getting able to decide
Where Exercise 2C fits.
Exercise 2 builds the conference package: which contribution sources must be represented, and what must they bring? 2C adds execution realism to the portfolio intent and Value Stream Initiative roadmaps.
2B · Value Stream Initiatives
Architecture, DevOps, platform, AI/data and compliance roadmaps.
2C · Executing Units
ARTs, Solution Areas, teams, departments and capacity realism.
2D · Central Functions
Finance, HR, legal, procurement and support constraints.
2E · External Suppliers
Lead times, interfaces, contracts and partner commitments.
Exercise output
An executing-unit contribution map: which units are in scope, who can represent them, which roadmaps and capacity views they bring, and where preparation gaps remain.
Core concept
What is an executing unit?
An executing unit is any social unit that contributes real delivery capacity to the Value Stream. It owns capacity, creates or enables value, and must be represented when conference decisions change its work.
It owns capacity
People, skills, work-in-progress, commitments and constraints determine what the Value Stream can realistically deliver.
It creates or enables value
It may build features, run operations, provide a platform, validate quality or execute traditional project work.
It must be represented
The room needs enough representation to make roadmap trade-offs without ignoring the people who must make the work happen.
It may be agile or not
ARTs, teams, departments, operations units, platform units and project organizations can all be executing units.
Why this matters
The conference needs delivery realism.
Portfolio intent and shared initiatives only become useful when executing units can absorb them. The conference integrates intent, foundations and unit-level feasibility.
Capacity realism
Roadmaps are credible only when they reflect real capacity, fixed commitments, maintenance load and unplanned buffer.
Feasibility insight
People close to the work know missing skills, integration bottlenecks, quality constraints and hidden dependencies.
Representation
The room cannot decide responsibly about a unit unless somebody can speak for constraints, options and ability to adapt.
Artifact updates
Every important decision should update a roadmap, board, dependency map, risk log or capacity assumption.
Anti-pattern
A beautiful roadmap is designed first and then the units are asked to make it work.
Core model
Executing units bring three truths.
Do not invite units because they exist. Invite them because their truth is needed for a decision.
Capacity
How much capacity is available after current commitments, KTLO, maintenance, compliance, enablers and buffer?
Feasibility
What can actually be delivered with current skills, architecture, integration windows, toolchain and dependencies?
Adaptability
Where can the unit re-sequence, absorb work, support another unit or change the collaboration structure?
Decision path
Start from the top flow problems.
The invite list is derived from the decisions the conference must be able to make. If a decision changes scope, sequence, capacity, staffing, architecture or commitments for an executing unit, that unit must be represented or immediately reachable.
Top flow problem
What blocks value creation most?
Business objective
Which objective is affected?
Executing unit
Which unit must contribute capacity or change behavior?
Representative
Who can speak for capacity, feasibility or decision rights?
Artifact
Which roadmap, board or evidence makes the decision possible?
Decision capability test
If the conference cannot update the unit roadmap, planning board, capacity forecast or dependency map, the decision will likely remain theatre.
Checklist · Step 1
Which executing units are in scope?
Use a fast yes/no/maybe scan before choosing representatives. Count roughly; precision can come later. Invite by decision need, not by org chart completeness.
| Executing unit type | Exists? | Count | Affected by top flow problems? | Needs conference representation? | Standby enough? | Notes |
|---|---|---|---|---|---|---|
| Agile Release Trains | □ | □ | □ | □ | ||
| Solution Trains | □ | □ | □ | □ | ||
| Solution Areas / domains | □ | □ | □ | □ | ||
| Agile Teams / Scrum Teams | □ | □ | □ | □ | ||
| Traditional departments | □ | □ | □ | □ | ||
| Project / program units | □ | □ | □ | □ | ||
| Platform / operations units | □ | □ | □ | □ | ||
| Other executing units | □ | □ | □ | □ |
Checklist · Step 2
What must the executing units bring?
Mark the minimum artifacts needed for a realistic conference. Missing inputs become part of the preparation backlog.
| Contribution artifact | Ready | Draft | Missing | Owner known? | Why it matters |
|---|---|---|---|---|---|
| Unit roadmap / plan | ○ | ○ | ○ | □ | Shows planned milestones, objectives and sequencing. |
| Capacity forecast / buckets | ○ | ○ | ○ | □ | Makes demand vs available capacity visible. |
| Fixed commitments | ○ | ○ | ○ | □ | Prevents over-planning by surfacing non-negotiable work. |
| Dependency / interface map | ○ | ○ | ○ | □ | Shows where units must coordinate, integrate or hand off. |
| Risks / blockers / impediments | ○ | ○ | ○ | □ | Turns known friction into decision material. |
| Skill / SME availability | ○ | ○ | ○ | □ | Identifies scarce experts and decision bottlenecks. |
| Quality / evidence / DoD constraints | ○ | ○ | ○ | □ | Connects feasibility to standards, validation and compliance. |
| Cannot absorb list | ○ | ○ | ○ | □ | Protects the conference from optimistic fantasy capacity. |
Snippet cards
Pick units, representatives, artifacts and invite modes.
The cards translate the deck into quick workshop prompts. Select only what your top flow problems and business objectives require.
Executing unit types
- Agile Release Train
- Solution Train
- Solution Area
- Agile Team
- Traditional Department
- Business Domain
- Platform / Operations Unit
- Legacy / Project Organization
Agile representatives
- Release Train Engineer
- Product Management
- System Architect
- Business Owner
- Product Owner
- Scrum Master / Team Coach
- Developer / SME
- Test / Quality Lead
Non-agile representatives
- Department Head
- Line Manager
- Project / Program Manager
- Domain Owner
- Operations Lead
- Planning / Capacity Owner
- Technical Lead
- Governance / PMO Lead
Contribution artifacts
- ART Roadmap
- Capacity Buckets
- Fixed Commitments
- Dependency Map
- Risk / Issue Log
- Skill / SME Map
- Evidence / Quality Plan
- Cannot-Absorb List
Invite mode
Choose the lightest mode that preserves decision capability.
Not every contributor needs to sit in the room for the full conference. Reduce full-room attendance by using block participation, standby windows and delegated representation — but never remove the path to a real decision.
Core conference participant
Needed across multiple agenda blocks; brings decision power or recurring capacity insight.
Block-only participant
Needed for one specific roadmap layer, flow problem or decision block.
Breakout participant
Needed in a targeted problem-solving room, but not in full plenary.
Standby participant
Available during a defined window and pulled in when a decision requires them.
Preparation-only contributor
Creates or validates the roadmap input but does not need to attend.
Delegated representation
One representative speaks for a unit after pre-alignment with affected people.
Two-step path
First conference representative, then targeted follow-up with the wider unit.
Not needed
Unit exists, but no current decision or flow problem needs its input.
Canvas · 2C
Executing Unit Contribution Board.
Map each executing unit to the decisions and artifacts it must support. The output links units to objectives, flow problems, representatives, artifacts, capacity assumptions and invite mode.
| Executing unit | Type | Affected objective / flow problem | Invitee / representative | Artifact brought | Capacity view | Decision enabled | Mode |
|---|---|---|---|---|---|---|---|
| ART A | ART | core / block / standby | |||||
| ART B | ART | core / block / standby | |||||
| Solution Area 1 | SA | core / block / standby | |||||
| Platform Unit | platform | core / block / standby | |||||
| Department X | dept. | core / block / standby | |||||
| Operations | ops | core / block / standby | |||||
| Own unit | core / block / standby |
Canvas · 2C
Representation and Invite Mode Matrix.
Use the columns as roles, not necessarily people. One person may cover multiple truths; one truth may need several people in preparation.
| Unit | Priority | Capacity | Architecture / technical | Flow / facilitation | Work reality / SME | Decision rights | Invite mode |
|---|---|---|---|---|---|---|---|
| ART A | □ | □ | □ | □ | □ | □ | core / block / standby |
| ART B | □ | □ | □ | □ | □ | □ | core / block / standby |
| Solution Train | □ | □ | □ | □ | □ | □ | core / block / standby |
| Solution Area 1 | □ | □ | □ | □ | □ | □ | core / block / standby |
| Traditional Dept. | □ | □ | □ | □ | □ | □ | core / block / standby |
| Platform / Ops | □ | □ | □ | □ | □ | □ | core / block / standby |
| Own unit | □ | □ | □ | □ | □ | □ | core / block / standby |
Canvas · 2C
Artifact Readiness Board.
Turn missing inputs into a preparation backlog before the Value Stream Conference invitations go out.
| Unit | Roadmap / plan | Capacity forecast | Dependencies | Risks / blockers | Owner | Due / trigger | Status |
|---|---|---|---|---|---|---|---|
| ART A | ○ | ○ | ○ | ○ | missing / draft / ready | ||
| ART B | ○ | ○ | ○ | ○ | missing / draft / ready | ||
| Solution Area 1 | ○ | ○ | ○ | ○ | missing / draft / ready | ||
| Platform Unit | ○ | ○ | ○ | ○ | missing / draft / ready | ||
| Department X | ○ | ○ | ○ | ○ | missing / draft / ready | ||
| Operations | ○ | ○ | ○ | ○ | missing / draft / ready | ||
| Own unit | ○ | ○ | ○ | ○ | missing / draft / ready |
Canvas · 2C
Decision Capability Matrix.
For each top flow problem, check whether the right units, representatives and artifacts are available. A “no” is valuable: it reveals a preparation gap that would have blocked the conference later.
| Flow problem / decision | Affected objective | Units affected | Needed representative | Artifact needed | Decision possible? | Gap / follow-up |
|---|---|---|---|---|---|---|
| Problem 1 | □ | |||||
| Problem 2 | □ | |||||
| Problem 3 | □ | |||||
| Roadmap trade-off | □ | |||||
| Capacity conflict | □ | |||||
| Dependency blocker | □ | |||||
| Own decision | □ |
Example
From flow problem to executing-unit contribution.
Example scenario: a shared platform bottleneck blocks multiple business objectives. The contribution package must connect the flow problem to the units, representatives and artifacts that make a decision possible.
Flow problem
Platform capacity and API readiness repeatedly delay three ARTs.
Who must contribute?
Platform Unit, ART A/B/C, System Architects and Operations.
Minimum artifact stack
Platform roadmap, ART capacity view, dependency map and decision backlog.
Decision needed
Which ARTs consume platform capacity now, and which work must be sequenced or stopped?
Facilitator flow
Run Exercise 2C in four passes.
Use this as the standard facilitation flow for a 20–25 minute exercise.
Inventory units
List ARTs, Solution Trains, Solution Areas, teams, departments and other execution structures.
Link to problems
For each top flow problem and business objective, mark the affected units.
Select representation
Choose who can represent priority, capacity, architecture, flow and work reality.
Check preparation
Mark roadmaps, capacity forecasts, dependencies and risks as ready, draft or missing.
Make it factual
Which artifact would make this discussion factual instead of opinion-driven?
Facilitator prompt
“Which unit would be surprised or blocked if this decision were made without them?”
Fast version
10-minute invite-and-prep hypothesis.
Use this when the group only needs a first invite-and-prep hypothesis.
Name the units
ARTs, Solution Areas, departments, teams, platform and operations.
Mark affected units
Use the top three flow problems only.
Pick representatives
Priority, capacity, feasibility and decision rights.
Mark artifacts
Roadmap, capacity, dependencies and risks.
Park gaps
Missing data becomes preparation backlog.
Debrief 2C
Are the executing units conference-ready?
Close the exercise by checking whether unit-level capacity and feasibility can actually enter the conference.
Coverage
Are all units affected by the top flow problems represented or reachable?
Capacity
Can the room see realistic capacity, fixed commitments and constraints?
Artifacts
Which unit roadmaps, boards or plans are ready enough to use?
Authority
Who can decide, and where do we only have information without authority?
Standby path
Which specialists or decision makers must be available during the event?
Preparation gaps
What must be clarified before invitations and pre-briefs go out?
Handoff
From executing units to central functions.
Exercise 2C makes delivery capacity visible. Exercise 2D checks which central functions can enable, constrain or invalidate the executing-unit contribution view.