DV-23
Issue Size Too Large for Hierarchy Level
Discipline
Default severity: medium
ProcessMetricsQuality
What it detects
An issue has story points above the configured maximum for its issue type — it is too large to be estimated reliably or completed within a sprint and should be broken down further.
Detection formula
max_sp = config.discipline.max_sp_per_type // e.g. {Story: 8, Task: 3, Sub-task: 2, Feature: 40} IF issue.story_points > max_sp\[issue.type\] THEN FLAG Severity = \'High\' if 1.5x max; \'Critical\' if > 2x max Report: issue_type, actual_sp, max_allowed_sp, recommended_action: \'decompose\'Examples in practice
- Assignee, field, hierarchy, or sprint hygiene rules are violated on active work.
- Issues miss mandatory fields or ownership while still in progress.
- A team shows an issue has story points above the configured maximum for its issue type while max sp per type is set to Map configured per issue type.
Suggested response
Enforce assignee, field, hierarchy, and sprint hygiene rules your team agreed on.
Coaching playbook
Symptom
An issue has story points above the configured maximum for its issue type — it is too large to be estimated reliably or completed within a sprint and should be broken down further.
Why it matters
When "Issue Size Too Large for Hierarchy Level" 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
Enforce assignee, field, hierarchy, and sprint hygiene rules your team agreed on.
Facilitation questions
- What system change would stop "Issue Size Too Large for Hierarchy Level" 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.