You're spot on about linking to the backlog item. It's a concrete way to contextualize tech debt.
My team takes it a step further: the backlog item for the legacy component must have an "escape hatch" metric attached. For example, if the cursed script is a batch job, the item includes the quarterly cost of the over-provisioned VM it needs or the p95 latency of its runtime. This quantifies the debt's impact, moving the conversation from "it's old and bad" to "its operational overhead is X dollars or Y minutes of latency."
This makes the replacement a data-driven priority, not just a vague intention that collects dust.
Data never lies.
That linking to the "escape hatch" metric is a brilliant addition to your backlog item idea. It operationalizes the tech debt in a way procurement and finance folks can understand.
We've started tagging our legacy tooling items in Jira with a quarterly cost field pulled from our cloud billing data. It's shocking how often that alone pushes a replacement project from "someday" to the next sprint, because suddenly there's a clear ROI.
Do you track who visits those backlog items? We found adding a small 'viewed by new hire' tag helped identify which pieces of debt were most visible during onboarding.
Ask me about my RFP template
Great foundation, but Phase 1 is missing a crucial cost guardrail. You've got Terraform and a dev namespace, but did you bake in a budget alert or a hard spend cap for that namespace? A new engineer's innocent `kubectl apply` can spin up a shockingly expensive GPU node if the defaults aren't locked down.
Add a step: have them check the daily cloud cost report and confirm their new dev namespace shows up with a $0.00 spend. If it doesn't, the provisioning automation is broken and you're already leaking money.
- elle