A records-retention team recodes production defects as new feature stories so velocity stays pretty. What should the SM/TC do?
Select an answer to reveal the explanation.
Short Explanation
Relabeling a leak as a new fountain does not dry the basement. If retention bugs become "features," the board looks busy while the same holes keep flooding flow. Leave defects in the open so the team can stop making them.
Full Explanation
Defects must stay visible as quality work so teams fix problems at the source. A records-retention team that recodes production defects as new feature stories to keep velocity pretty is hiding quality trouble in feature accounting—dangerous for civic retention obligations. The Scrum Master/Team Coach should keep defects visible, analyze causes, and improve built-in quality rather than launder rework into feature counts.
Continuing to recode defects as features so dashboards never show quality trouble fails by concept: it optimizes vanity metrics while retention risk remains. Freezing all retention features until velocity matches last PI’s inflated number fails by concept by treating the gamed baseline as truth and stopping value. Handing defect accounting to Finance so the team can ignore quality metrics fails by concept because quality empiricism belongs with the delivering team’s flow system.
Exam caveat: SAFe and agile coaching treat transparent defect/rework data as essential; gaming velocity by misclassification is an anti-pattern. Visibility enables root-cause improvement—not ritual shame—for public records systems.
Operational check: stop recoding production defects as features, tag and chart defect/rework distinctly on the retention board, review top causes in retrospectives, and show declining escaped defects rather than inflated feature velocity.