Complete firstProcess Mapping
A documented process or value stream with steps, handoff points, and throughput per step exists.
Without: Without process mapping, the constraint cannot be identified systematically and TOC becomes a constraint guess.
RunsheetOperations
Theory of Constraints
ComplexityHigh
Time2-4 h Analyse, laufend
Participants3-12
FormatWorkshop + async
MaturityCanonical
01
Prerequisite
What needs to be finished first
Complete firstValue Stream Mapping
A Value Stream Map with processing and waiting times per step is available or is created as part of the TOC application.
Without: Without time data, it remains unclear whether the constraint is real or whether local optimization is being requested.
02
Preparation
What needs to be ready before start
Materials
Whiteboard with process overview; data on throughput, WIP, waiting times per step; poster with TOC Five Focusing Steps; markers; template for constraint measures.
People / roles
One TOC coach or Lean-experienced facilitator; 4-8 people with process and data knowledge (Ops, Engineering, Management); one scribe; for cross-department constraints, representatives of all affected areas.
Pre-read
Process map with throughput data per step (last 4-12 weeks); known complaints about waiting times or bottlenecks; current improvement initiatives; target metric (throughput, lead time, variability).
Time needed
Initial workshop 3-4 h, then iterative reviews every 2-4 weeks
Setup
Show process map with throughput per step. Five Focusing Steps as wall poster: 1) identify the constraint, 2) exploit the constraint, 3) subordinate everything else to the constraint, 4) elevate the constraint, 5) when the constraint is broken, go back to step 1. Data snapshot with timestamp.
03
Core question
The one question this method answers
Which process step currently limits overall throughput, how can this constraint be exploited to the maximum, and which escalation level (exploit, subordinate, elevate) is next?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Identify the constraint | 45-60 min | Make throughput, WIP, and waiting time visible for each process step. The constraint is the step with the highest WIP before it and throughput below demand. Agree on the one constraint. | Common mistake: political constraint (the step with the loudest complaints) instead of data-based constraint. Data wins, not perception. With several candidates, use Little's Law as test. |
2Phase 2: Exploit the constraint | 45-60 min | Determine how the constraint step is used maximally: no interruption through defects, no idle time, no duplicate work. Define concrete measures for the next 2 weeks. | Exploit does not mean overload. The constraint must not wait for missing inputs, but must also not be blocked by defective work. Quality control before the constraint, not after it. |
3Phase 3: Subordinate the rest | 30-45 min | Tune all non-constraint steps to the constraint rhythm. Upstream steps provide only as much as the constraint can take. Downstream steps are faster than the constraint and may wait occasionally. | Local optimization of non-constraints harms the system. Making engineering faster when code review is the constraint builds WIP, not throughput. Subordination is often the hardest step. |
4Phase 4: Elevate the constraint | 30-45 min | If the constraint still limits after phases 2 and 3, increase capacity (investment, people, tool). Define measures with cost and expected benefit, decide on investment. | Elevating is the most expensive level and should come last. Often phases 2 and 3 reveal that the constraint moves before investment is needed. |
5Phase 5: Review and movement | 30 min, then every 2-4 weeks | After 2-4 weeks, check whether the constraint is still the same or has moved. If it moved, identify the new constraint and repeat steps 2-4. If it did not move, check why. | Constraints often move faster than expected. Anyone knowing the same constraint for 3 months has either not run phase 4 or has an organizational constraint (policy, contract), not an operational one. |
05
Artifact
What comes out at the end
Form
Documentation with current constraint, data evidence, measures per Five Focusing Step with owner and date, implementation status, and review results. Timeline of the constraint across several iterations (constraint movement map).
Versioning / ownership
Per iteration, record date, identified constraint, data snapshot, and measures taken. Do not overwrite history; movement map shows structural patterns.
Tool alternatives
- Confluence page with tables per iteration
- Notion database with columns Iteration, Constraint, Measure, Status
- Miro board with process map and constraint highlight per iteration
- Markdown in the repo under docs/operations/toc-<date>.md
theory-of-constraints-working-template.md
Compact working template for Theory of Constraints with context, input, output artifacts, and next step.
Theory of Constraints Canvas
Context
What is this method used for?
Core question
Which question should be answered at the end?
Input
Which data, observations, or materials are available?
Working area
- Area 1:
- Area 2:
- Area 3:
- Relationships / patterns:
Output artifacts
- Constraint Map:
- Improvement Plan:
- Flow Metrics:
Open questions
- ...
Next step
Owner, date, success signal.
06
Example output
Concrete filled scenario, fictional example
theory-of-constraints-beispiel.md
Concrete filled scenario, fictional example
TOC - Engineering Tribe Aurora, Iteration 3, 2026-06-15
Data (Sprint 11-12): Stories average 14 days lead time, 8 of them waiting in "Ready for Review".
Constraint: Code Review
- WIP in Review: average 9, max 14.
- Review throughput: 4 Stories/week, Engineering throughput: 7 Stories/week.
- Data evidence: Linear Cycle Time report, snapshot from 2026-06-14.
Measures
- Exploit: Reviewer slot 14:00-16:00 blocked daily, no meetings. Pre-review checklist in PR template reduces rework. Owner @ben, from 2026-06-17.
- Subordinate: WIP limit "in Progress" reduced to 5 Stories per engineer, new Stories wait in Ready. Pull instead of push. Owner @sabine, from 2026-06-17.
- Elevate: Pilot senior engineer as second reviewer role if WIP remains above 7 after 2 weeks. Decision on 2026-07-01 with data check.
Previous constraint
Iteration 2 (May): constraint was QA. After test automation, constraint moved to Review (expected, but faster than planned).
07
Pitfalls
Recognize symptoms and steer against them
Trap
Political constraint instead of data constraint
Symptom
Team agrees on the step with the loudest complaints, data contradicts it.
What to do
Base constraint identification strictly on data: WIP, throughput, waiting time. If no data is available, measure before the workshop. Treat complaints as hints, not proof.
Trap
Local optimization beyond the constraint
Symptom
Team optimizes steps that are already faster than the constraint, builds WIP before it, lead time rises.
What to do
Clear rule: only the constraint step is optimized. Other steps are subordinated, meaning deliberately slowed down or controlled with WIP limits. Pause local efficiency metrics.
Trap
Constraint movement unexpected
Symptom
After measures, the new constraint appears elsewhere, team does not react and keeps treating the old constraint.
What to do
Maintain review cadence (2-4 weeks). Recollect data and identify the constraint anew. If movement is detected, freeze old measures and make the new constraint the focus.
Trap
Elevating too early
Symptom
Team increases capacity before phases 2 and 3 are exhausted. Investment is expensive, effect is low.
What to do
Follow the Five Focusing Steps in order. Before elevation, check: is the constraint truly fully utilized, has subordination happened. If not, go back to phase 2.
Trap
Organizational constraint not recognized
Symptom
The constraint is not a process step but a policy or contract clause (for example CFO approval for every deploy).
What to do
Expand constraint definition to policy constraints. Use TOC Thinking Process or Evaporating Cloud as follow-up method for policy constraints.
08
Stop criteria
Done signals checkable in under a minute
No reliable data on throughput and waiting time per process step, constraint cannot be identified.
Process is unstable or new, no steady state, constraint changes daily.
Political conflicts around constraint identification, data is ignored or disputed.
Sponsor for subordination is missing, non-constraint steps insist on local efficiency.
Constraint is outside the team's control (supplier, regulation), TOC needs different levers.
Time window for review cadence is not established, method stops at phase 1.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.