TQ-29

Split Requirement Summary Series in Initiative Scope

Text Quality

Default severity: high
ProcessMetrics

What it detects

Two or more issues in initiative scope share the same base summary after stripping continuation or part suffixes (cont., pokračovanie, part 2, Roman numerals) but titles are not identical — split-work naming instead of one traceable item.

Detection formula

IF normalized base summary matches ≥2 issue keys AND raw summaries differ (exact duplicates are TQ-24) THEN FLAG all

Examples in practice

  • Improve login performance and Improve login performance, cont. as separate Stories.
  • Payment retry flow I and Payment retry flow II without a parent epic.

Suggested response

Merge into one item with sub-tasks, link as relates/depends, or rename so each summary is distinct and self-contained.

Coaching playbook

Symptom

Two or more issues in initiative scope share the same base summary after stripping continuation or part suffixes (cont., pokračovanie, part 2, Roman numerals) but titles are not identical — split-work naming instead of one traceable item.

Why it matters

When "Split Requirement Summary Series in Initiative Scope" 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

Merge into one item with sub-tasks, link as relates/depends, or rename so each summary is distinct and self-contained.

Facilitation questions

  • What system change would stop "Split Requirement Summary Series in Initiative Scope" 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.

Product tourSign in
TQ-29: Split Requirement Summary Series in Initiative Scope — FlowAnalyzer