Lesson 3 of 3
The two-minute rule
A BPMN diagram that requires more than two minutes to explain is probably too complex for its intended audience. This is a practical heuristic used by experienced BAs and process consultants — not a formal BPMN specification rule, but consistently reliable.
Apply before every stakeholder presentation
Before sharing a diagram with a stakeholder, try explaining it in two minutes. If you cannot — simplify first. A stakeholder who cannot follow the diagram will not give you useful feedback on it. A confused audience means the model has failed its primary purpose, regardless of technical accuracy.
Signs a diagram needs simplification
- More than 20 elements on one canvas. Not a hard limit, but a reliable signal. 20 elements with many crossings and nested gateways is almost always unreadable.
- Flows crossing each other more than twice. Crossing arrows create visual noise. More than two crossings signals a layout problem, not a content problem.
- More than two nested levels of gateways. A gateway inside a gateway inside a gateway is almost certainly a Sub-process in disguise.
- Tasks that are really sub-processes. If every stakeholder immediately asks 'but what does that involve?' when they see a task — it should be a collapsed Sub-process.
- The eye-glaze test. Present the diagram to someone unfamiliar with the process. If their eyes glaze within 30 seconds without you saying anything, the diagram is too complex.
The solution: Sub-processes and levels of abstraction
A Sub-process (a task shape with a `+` in the bottom centre) collapses a group of related tasks into a single shape at the top level, while preserving the detail in a nested diagram that can be opened if needed.
Example: A high-level invoice approval process shows 'Handle Invoice Discrepancy' as a simple task. When stakeholders need to know what that involves, a Sub-process reveals: 'Contact Supplier', 'Log Discrepancy in System', 'Receive Supplier Response', 'Re-enter Corrected Invoice'. The high-level diagram stays clean; the detail is available but not forced on every viewer.
Bruce Silver's levels of BPMN
| Level | Name | Audience | Appropriate complexity | Typical use |
|---|---|---|---|---|
| 1 | Descriptive BPMN | Business stakeholders, executives, non-technical reviewers | Low — happy path, key decisions, major roles only | Workshop facilitation, executive communication, initial documentation |
| 2 | Analytical BPMN | Business analysts, process architects, technical BAs | Medium — includes exceptions, timers, data objects, escalation paths | Detailed requirements documentation, process improvement analysis |
| 3 | Executable BPMN | Process automation engineers, developers | High — technically precise, all execution semantics, task markers, DMN links | Workflow automation, Camunda/Bizagi implementation |
BA positioning principle
Your job as a BA is usually to produce Level 1 diagrams for business communication and Level 2 diagrams for detailed requirements. Level 3 is the developer's responsibility, using your Level 2 model as the specification. Conflating all three in a single diagram produces a model that is too complex for the business and not precise enough for developers.
When to use Sub-processes
- When a task contains three or more internal steps that are relevant to the audience at this level.
- When a section of the process repeats under a loop condition.
- When exception handling is complex enough to deserve its own diagram.
- When a complex task is reused in multiple process models (a Call Activity).
✓ When to use
- Apply the two-minute rule before presenting any diagram to a new audience
- Use Sub-processes to collapse detail that is important but not needed at the current level of abstraction
- Match diagram complexity to the audience level — descriptive for executives, analytical for BAs
✗ When not to use
- ✕Don't collapse detail just because the diagram looks busy — complexity is sometimes inherent in the process
- ✕Don't use Sub-processes to hide complexity from reviewers — only to defer it to the right audience
- ✕Don't simplify to the point of omitting important exceptions or decision logic