Refine the Roadmap and Test How the Value Stream Should Collaborate
Use Day 2 to close the most important roadmap gaps and frame changes to Solution Areas, ARTs, teams, platforms, communities, decision paths, and syncs as testable hypotheses. Involve the people affected, define what better Flow would look like, and route validation into the refinement cadence.
- Fast exercise
- 5 minutes
- Full exercise
- 25–45 minutes
- Input
- Adjusted draft + Day 2 focus
- Output
- Roadmap + operating-model hypotheses
- Deck basis
- Slides 57–58
Understanding Day 2 Breakouts
Roadmap choices and collaboration design shape each other
Timing, sequence, capacity, dependencies, ownership, and architecture often reveal that the current collaboration structure cannot support the intended Flow. Day 2 makes those tensions explicit without treating a workshop sketch as a finished reorganization.
Roadmap and Operating Model
Refine what must happen and how people must interact
Organize around Value as Hypothesis
Design for better Flow, then test the consequences
Organizing around value is not synonymous with drawing a new org chart. Start from a specific Flow problem, describe the proposed boundary or interaction change, state the expected outcome, and define how the people affected will challenge and validate it.
Which waiting, handoff, overload, queue, dependency, feedback, or decision delay should improve?
Boundary, team, Solution Area, ART, platform, community, role, interaction, or sync hypothesis.
Faster decision, fewer handoffs, clearer ownership, lower cognitive load, better quality, or shorter feedback.
Who performs, consumes, owns, supports, governs, supplies, or is constrained by the change?
New dependencies, capability gaps, local optimization, transition cost, ambiguity, or loss of resilience.
What evidence, simulation, conversation, experiment, measure, and review date would change confidence?
Use when several units need intensive joint learning or design; define the outcome and when the collaboration can end.
Use when a platform or shared service can reduce coordination through reliable ownership, interfaces, and experience.
Use when expertise should unblock or grow capability temporarily rather than become a permanent dependency.
Optional lens: These interaction modes can sharpen a hypothesis; they are not a requirement to adopt Team Topologies as a full operating model.
Running the Exercise
Five moves from adjusted draft to refinable collaboration hypotheses
-
1
Approximately 4–8 minutes
Select Day 2 Themes from the Planning Adjustment
Choose the few gaps and hypotheses that most affect the draft roadmap. Carry forward unresolved Day 1 work only when the new guardrails or evidence make a materially better outcome possible.
Roadmap Refinement Clarify timing, sequence, owners, milestones, confidence, and unresolved dependencies.
Organize around Value Which collaboration structure would improve the targeted value Flow?
Solution Area Adjustment Move, split, combine, or strengthen Solution Areas as a hypothesis.
ART / Solution Train Cut Test whether trains still match the value stream, dependencies, and decision demand.
Team Structure Hypothesis Should teams change, collaborate differently, or form temporary cross-unit groups?
CoP / Community Design Architecture, DevOps, cyber, AI, compliance, platform, quality, or supplier communities.
Platform Consumption How can units use common capabilities without blocking one another?
Architecture / API Governance Who decides interfaces, standards, evolution paths, exceptions, and evidence?
Refinement Cadence Which refinements happen before Final Sync and PI Planning?
Sync Meeting Design Which syncs are decision and artifact-update events rather than status meetings?
Operating Model Hypothesis How should the Value Stream collaborate during the next learning horizon?
Validation Card Who affected by the hypothesis must inspect, challenge, and adapt it?
Day 2 Theme Selection Theme Roadmap gap Flow problem Hypothesis needed Decision / validation window Expected output Integration structure unclear sequence owner cross-ART waiting temporary Solution Area Day 2 14:00 roadmap + experiment Platform usage adoption milestones shared expert queue service + enabling path Final Sync consumption model Speaker Notes
Facilitator intentSelect Day 2 breakout themes that refine the roadmap and test collaboration structure based on Day 1 learning, not based on the original agenda alone.
How to facilitate
- Start from the reset Day 2 focus backlog and choose themes that close roadmap gaps, organization hypotheses, CoP needs, platform usage, decision model, or sync cadence.
- For each theme, state the roadmap question, affected people, validation needed, and intended output.
- Limit themes to what can materially improve the draft roadmap or operating model before Final Alignment.
Listen and watch for
- Day 2 themes chosen because they are popular, not because Day 1 changed the decision basis.
- Roadmap refinement and organization design mixed without knowing which output is expected.
- Too many themes, causing thin participation and weak artifact updates.
Avoid
- Treating Day 2 as a second Day 1. Day 2 should sharpen, validate, and make the draft usable.
- Letting organizational design conversations run without a roadmap problem to solve.
- Ignoring unresolved Day 1 evidence because Day 2 already had planned topics.
-
2
Approximately 5–10 minutes
Frame Organization Hypotheses from Flow Problems
Prevent preferred structures from appearing as solutions without a problem. For every proposal, make the current Flow mechanism, expected improvement, affected people, trade-offs, and validation path visible.
Problem-groundedNames an observable Flow mechanism Waiting, handoff, overload, queue, dependency, feedback, ownership, or decision delay.
Outcome-orientedExplains what becomes better Decision speed, Flow time, quality, learning, capacity, customer feedback, or reliability.
BoundedChanges the smallest useful unit Interaction, responsibility, temporary group, Solution Area, service, sync, or train boundary.
Human-awareNames the people and work affected Include cognitive load, skills, identity, authority, career, support, and transition reality.
Trade-off-awareShows what could worsen New coordination, capability gaps, local optimization, fragility, governance, and transition cost.
TestableHas evidence and a review point Prototype, simulation, trial horizon, measure, affected-person feedback, and decision date.
Organization Hypothesis Backlog Flow problem Proposed change Expected outcome Affected people Risk Test / evidence Owner + review integration decisions wait 12 days temporary Integration Solution Area decision within 3 days ART A/B, architects extra meeting load one-PI trial STE · Final Sync platform team becomes ticket queue service + enabling interaction fewer escalations platform + consumers consumer skill gap two adoption slices Platform PM · 6 weeks Speaker Notes
Facilitator intentFrame organize-around-value ideas as hypotheses to be tested with affected people, not as management decrees hidden inside a roadmap workshop.
How to facilitate
- Write the hypothesis as: if we change collaboration structure in this way, Flow improves for this objective or problem, because this interaction changes.
- Name affected ARTs, Solution Areas, teams, CoPs, suppliers, platforms, and decision interfaces.
- Define the validation needed: who must inspect the hypothesis, what evidence would support it, and what risk would make it unsafe.
Listen and watch for
- Structure changes proposed as obvious fixes without linking them to Flow problem, objective, or roadmap gap.
- People affected by the change not present or not scheduled to validate it.
- Permanent operating-model language used for what should be a PI-level experiment.
Avoid
- Finalizing organization design in the agenda design exercise.
- Using the conference to impose a train cut, team structure, or CoP model without inspect-and-adapt path.
- Treating every collaboration issue as an org-chart issue. Many are policy, cadence, artifact, or decision-right issues.
-
3
Approximately 5–10 minutes
Map the Interaction, Decision, Artifact, and Cadence Changes
A structural label alone does not explain how work will move. Show who interacts, for what purpose, through which decisions and artifacts, with what duration, and how the interaction ends or evolves.
Units Teams, Solution Areas, ARTs, trains, platforms, functions, partners, customers, and communities.
Purpose Joint discovery, integration, service, enablement, governance, evidence, decision, or learning.
Mode Collaboration, service, facilitation, community, decision window, standby, or direct handoff.
Decision rights Local authority, shared agreement, centralized guardrails, escalation, and delegate.
Artifacts Roadmap, backlog, interface, service contract, risk, decision log, board, or evidence chain.
Cadence / trigger Continuous, weekly, per iteration, milestone, decision age, risk trigger, or temporary window.
Success signal Waiting, rework, handoff, decision time, quality, adoption, feedback, or workload change.
Evolution rule When should the interaction stop, change mode, expand, shrink, or become a stable capability?
ART A + ART B↔Temporary collaboration→Integration decision log→Weekly for 6 weeks→Review handoff timeSpeaker Notes
Facilitator intentMap the concrete interaction changes needed for roadmap refinement: which roles, artifacts, decisions, syncs, or handoffs must change for the hypothesis to work.
How to facilitate
- For each theme, name what changes in interaction: decision owner, artifact owner, sync cadence, interface rule, platform consumption, CoP involvement, or validation path.
- Tie each interaction change to a roadmap entry or risk; otherwise it remains an operating-model wish.
- Identify whether the change is a one-time conference output, a refinement cadence item, or an execution-cadence item.
Listen and watch for
- Generic collaboration language such as align better, stronger ownership, or more transparency without a changed interaction.
- New syncs created without artifact update, decision right, or trigger. That becomes meeting load.
- Interaction changes that depend on people or functions not in the validation path.
Avoid
- Over-designing the future operating model instead of mapping the next useful interaction change.
- Creating a sync for every problem. Some problems need a decision rule, artifact owner, or clearer interface instead.
- Ignoring the difference between refinement before PI Planning and execution realignment after PI Planning.
-
4
Approximately 5–10 minutes
Validate with the People Who Must Make the Hypothesis Work
Invite affected people to inspect the Flow problem, proposed change, expected outcome, operational consequences, and experiment. Validation is not a ceremonial vote; it is evidence that can change the hypothesis.
Work realityDoes the proposal match how value and information actually move? Surface hidden handoffs, support work, local constraints, and informal coordination.
CapabilityCan the proposed unit perform the responsibility? Skills, capacity, tooling, decision authority, access, platform support, and learning needs.
Cognitive loadDoes the change simplify or overload? Domain breadth, interruptions, coordination, operational ownership, and competing priorities.
InterfacesWill boundaries become clearer? Inputs, outputs, quality, service expectations, escalation, decision rights, and ownership.
TransitionWhat must change safely? Work in progress, responsibilities, careers, contracts, metrics, access, communication, and support.
Learning designWhat evidence would change our mind? Experiment horizon, baseline, measure, review, stop rule, and supersession decision.
Organization Hypothesis Validation Plan Hypothesis People affected Validation method Evidence / measure Owner By when Decision after validation Integration Solution Area ART A/B teams, architects mapping + one-PI trial decision age + handoffs STE Final VS Sync continue / adapt / stop Platform service model platform + 3 consumer teams service prototype adoption + support load Platform PM 6 weeks scale / enable / revise Speaker Notes
Facilitator intentValidate roadmap and operating-model hypotheses with the people affected before the conference treats them as credible draft decisions.
How to facilitate
- Bring affected people into the room or validation window: teams, ART reps, Solution Areas, CoP owners, suppliers, operations, and central functions where relevant.
- Ask what would make the hypothesis wrong, unsafe, too expensive, or unworkable. Preserve dissent as evidence, not resistance.
- Use confidence and validation status: accepted for draft, needs refinement, unsafe, or route to another decision body.
Listen and watch for
- Affected groups learning about the hypothesis only after Final Alignment.
- Validation reduced to consent language, while feasibility, capacity, and quality concerns remain unresolved.
- A high-confidence label based on leadership agreement rather than affected-person validation.
Avoid
- Equating stakeholder buy-in with validation. The question is whether the structure can work in the real work system.
- Treating every objection as a blocker. Some objections are validation data for refinement.
- Moving unvalidated organizational hypotheses into the roadmap as if they were confirmed decisions.
-
5
Approximately 4–8 minutes
Update the Roadmap and Operating-Model Hypothesis Together
Capture the refined roadmap entry, collaboration hypothesis, owners, validation work, decision rights, cadence needs, risks, and review point in connected artifacts. The roadmap says what must move; the operating-model hypothesis says how the system will learn to move it.
Roadmap deltaTiming, sequence, scope, owner Include assumptions, dependencies, capacity, confidence, and unresolved questions.
Organization hypothesisBoundary or interaction change Connect the Flow problem, expected outcome, affected people, trade-offs, and test.
Decision modelAuthority and escalation Clarify local choices, shared agreements, guardrails, delegates, and decision windows.
Interaction mapPurpose, mode, artifact, duration Show how teams, trains, platforms, functions, partners, and communities collaborate.
Refinement backlogValidation and implementation work Owners, minimum evidence, due dates, measures, risks, and next decision.
Cadence needSync or trigger Route the work into Final Sync, PI Planning, community, architecture, supplier, or other refinement loops.
Day 2 breakout handoff We refined [roadmap entry] and propose [organization hypothesis]. [Affected people] will validate it through [work] by [date]; [owner] will update [artifact], and [next sync] will decide [continue, adapt, scale, or stop].Day 2 Breakout release rule READYroadmap gaps and collaboration changes are connected, affected people can influence the hypothesis, and validation has owners, evidence, and a decision date
NOT READYthe room has drawn a future org chart, assigned people without them, or created syncs with no decision or artifact purpose
Speaker Notes
Facilitator intentUpdate the draft roadmap and operating-model hypothesis together so timing, ownership, refinement cadence, and validation remain connected.
How to facilitate
- For every Day 2 output, update the roadmap entry, operating-model note, owner, decision log, risk, and next refinement step.
- Distinguish confirmed draft decisions from hypotheses that require validation after the conference.
- Prepare the Final Alignment handoff: what changed, who owns it, confidence, risk, and what must be reviewed before PI Planning.
Listen and watch for
- Roadmap entries updated without the collaboration structure needed to make them real.
- Operating-model decisions documented separately from the roadmap, causing them to be forgotten during refinement.
- Outputs that lack owner, review date, or artifact path.
Avoid
- Claiming the roadmap is final. The deck frames the output as a draft for refinement.
- Leaving structural hypotheses as whiteboard notes instead of artifact updates.
- Entering Final Alignment with multiple conflicting versions of the draft.
Facilitation
Keep organizational design close to Flow, people, and evidence
Return to the Flow problem, value boundary, decisions, handoffs, waiting, cognitive load, and expected outcome.
Rewrite it as a hypothesis with affected people, test horizon, success signal, review date, and stop rule.
Pause. Name who must validate, what work and identity are affected, and how the transition decision will be made.
State the decision or artifact-update job, cadence trigger, participants, owner, and condition for merging or stopping it.
Inspect consumer needs, ownership, service experience, enablement, interfaces, and the interaction mode—not only team labels.
Ask what evidence, risk, work reality, or consequence would change the hypothesis and who can provide it.
Ready to Move On?
Day 2 Breakouts are ready when roadmap and collaboration can be refined together
- Day 2 themes come from the adjusted roadmap, unresolved decisions, and highest-leverage Flow problems.
- Every organization proposal names the observable problem it is intended to improve.
- Roadmap timing, ownership, dependencies, decisions, and refinement path are explicit.
- Solution Area, ART, train, team, platform, community, and sync changes remain hypotheses.
- Expected outcomes and possible negative trade-offs are visible.
- Interaction purpose, mode, decision rights, artifacts, cadence, and evolution rule are defined.
- The people affected by each hypothesis are identified and able to challenge it.
- Capability, cognitive load, interfaces, transition, and learning design are considered.
- Validation has a method, evidence, owner, date, and next decision.
- Roadmap and operating-model artifacts are updated together.
- Refinement work and cadence needs are routed to explicit next syncs.
Source Foundation
This page distills slides 57–58 of 05 Value_Stream_Conference.pptx. Organization Hypothesis Cards, interaction-mode lenses, affected-person validation, evolution rules, and connected roadmap/operating-model updates are facilitator extensions. Team Topologies is used selectively as an interaction-design lens rather than imposed as a second framework.