Planning
AuraScore 87/100

Technical Debt Remediation Prioritization Matrix

Evaluate software debt backlog items and build a weighted prioritization matrix aligned with engineering capacity and strategic goals.

Use this template when planning quarterly engineering roadmaps to balance refactoring efforts against new feature delivery. It guides technical leaders in systematically ranking technical debt items into clear delivery tiers.

Template

Role: Principal Enterprise Architect with fifteen years of experience guiding software teams through modernization and technical debt prioritization.

Context

  • Software platform under evaluation: {{software_platform}}
  • Candidate debt and refactoring backlog: {{tech_debt_items}}
  • Strategic business milestones: {{business_objectives}}
  • Team allocation and resource limits: {{engineering_capacity}}
  • Organizational posture toward deployment risk: {{risk_tolerance}}
  • Prioritization dimensions: {{evaluation_criteria}}

Task

Evaluate the candidate technical debt backlog items against strategic velocity and stability risks, synthesizing them into an actionable, weighted remediation matrix to determine exact implementation sequence for upcoming engineering sprints.

Method

  1. Parse each item in {{tech_debt_items}} to define its primary failure mode and system blast radius within {{software_platform}}.
  2. Evaluate the direct negative impact of each item on developer velocity and ongoing maintenance overhead.
  3. Score alignment between resolving each candidate item and accelerating {{business_objectives}}.
  4. Gauge the architectural implementation risk of each remediation effort against {{risk_tolerance}}.
  5. Map implementation effort per item against available team bandwidth documented in {{engineering_capacity}}.
  6. Apply weights across {{evaluation_criteria}} to generate a composite priority index score for each item.
  7. Group prioritized items into immediate sprint, scheduled next, or backlog parking lot tiers.

Constraints

  • MUST present the primary evaluation as a structured Markdown comparative matrix table.
  • MUST assign a definitive composite score or priority tier to every candidate item.
  • MUST NOT recommend changes that exceed the stated resource envelope in {{engineering_capacity}}.
  • Limit architectural justification per item to two concise sentences.
  • Base all trade-offs directly on the constraints articulated in {{risk_tolerance}}.

Output format

Produce the output in the following distinct sections:

  1. Executive Context: A 2-sentence summary of overall system posture.
  2. Remediation Priority Matrix: A Markdown table containing columns for Debt Item, Affected Subsystem, Effort Estimate, Business Value Impact, Operational Risk, Weighted Priority Score, and Recommended Phase.
  3. Phase Allocation Breakdown: A bulleted implementation plan grouped by release phase (Immediate, Next, Deferred) matching capacity constraints.
  4. Critical Trade-offs: 3 high-impact risks mitigated or accepted by this sequencing.

Self-review

  • Confirm all items from {{tech_debt_items}} appear in the matrix.
  • Ensure total effort in the immediate tier does not exceed {{engineering_capacity}}.
  • Check that scoring explicitly reflects the criteria defined in {{evaluation_criteria}}.
  • Verify markdown table formatting parses cleanly without truncated cells.
AuraScore breakdown
87/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification14/14 · Strong

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

business-strategy
business-planning
technology-software
planning
software-engineering
tech-debt