VS-04
Graph Depth Exceeds Configured Maximum
Value Stream Graph
Default severity: medium
PrioritizationProcessOutputRisk
What it detects
The delivery hierarchy for an Initiative has more levels than the configured maximum — the graph is too deep to manage or visualise effectively, and items at the bottom of the hierarchy are invisible to PI planning. depth = MAX(shortest_path_length, from_initiative_root_to_any_leaf)
Detection formula
IF depth > config.graph.max_hierarchy_depth // default: 4 (Initiative->Epic->Feature->Story) THEN FLAG over_deep Report: deepest paths, nodes at each levelExamples in practice
- Dependency links or initiative graph paths are missing, cyclic, or blocked.
- Downstream work waits on unresolved upstream dependencies.
- A team shows the delivery hierarchy for an initiative has more levels than the configured maximum while max hierarchy depth is set to 4 (Initiative->Epic->Feature->Story).
Suggested response
Repair dependency and initiative graph links so delivery paths and handoffs are explicit.
Coaching playbook
Symptom
The delivery hierarchy for an Initiative has more levels than the configured maximum — the graph is too deep to manage or visualise effectively, and items at the bottom of the hierarchy are invisible to PI planning. depth = MAX(shortest_path_length, from_initiative_root_to_any_leaf)
Why it matters
When "Graph Depth Exceeds Configured Maximum" keeps appearing, the team is signalling a repeatable process gap. Left unexamined, the pattern hides where work really stalls and makes improvement metrics harder to trust.
What you can achieve
Repair dependency and initiative graph links so delivery paths and handoffs are explicit.
Facilitation questions
- What system change would stop "Graph Depth Exceeds Configured Maximum" from firing again?
- What do the cited issues have in common — same root cause or same workaround?
- Who owns the two-week experiment and how will we verify on the next import?
Run this rule against your own tracker data with Flow Analyzer.