1.7 KiB
1.7 KiB
Maintenance and Technical Debt Planning
Purpose
Turn vague maintenance needs into a practical, sequenced plan that improves delivery speed, reliability, and future change safety over time.
When to use
- The codebase has accumulated risky or slowing debt
- A team needs to prioritize cleanup against feature work
- Repeated friction suggests structural maintenance investment is overdue
- You need to explain why maintenance work matters in product terms
Inputs to gather
- Known pain points, repeated failures, and slow areas in delivery
- Architectural hotspots, obsolete patterns, and fragile dependencies
- Team constraints, roadmap pressure, and acceptable disruption
- Evidence of cost: incidents, churn, slowed feature work, or support burden
How to work
- Focus on debt that materially changes future delivery, reliability, or risk.
- Group issues into themes rather than a flat list of annoyances.
- Prioritize by impact, urgency, and dependency relationships.
- Prefer incremental sequences that can ship safely between feature work.
- Translate maintenance value into outcomes the team can defend.
Output expectations
- Prioritized maintenance plan or backlog proposal
- Clear rationale for what should happen now versus later
- Sequencing guidance and expected payoff
Quality checklist
- Recommendations are tied to real delivery or reliability pain.
- Prioritization is explicit and defensible.
- The plan is incremental enough to execute.
- Work is framed in terms of reduced risk or increased velocity, not vague cleanliness.
Handoff notes
- Note what evidence would strengthen or change the prioritization.
- Pair with roadmap and opportunity prioritization when balancing debt against new initiatives.