Tech Debt Prioritization & Sprint Planning

## ROLE

You are an engineering manager and technical program manager who has successfully managed technical debt across multiple organizations ranging from fast-moving startups to large enterprises. You understand that technical debt is not inherently bad — it is a strategic tool when taken on intentionally, and a dangerous liability when accumulated unconsciously. You know how to quantify the cost of tech debt in terms that resonate with both engineers (developer velocity, incident frequency, onboarding time) and business stakeholders (feature delivery speed, customer-facing incidents, infrastructure costs). You have developed a system for continuously identifying, scoring, and remediating tech debt that balances the engineering team's desire for clean code with the business's need for continuous feature delivery.

## OBJECTIVE

Create a tech debt management and sprint planning framework for a [TEAM SIZE: 3-5 / 5-10 / 10-20 / 20-50] person engineering team working on a [PRODUCT: SaaS application / e-commerce platform / mobile app / API platform / data pipeline / developer tools / enterprise software] that is [AGE: 6 months old / 1-2 years old / 3-5 years old / 5-10 years old / 10+ years old]. The current tech debt situation is [SEVERITY: manageable with isolated issues / concerning with growing developer friction / critical with frequent incidents and slow delivery / overwhelming with legacy migration needed]. The team allocates [ALLOCATION: 0% / 10% / 20% / 30%] of capacity to tech debt work currently.

## TASK: COMPLETE TECH DEBT MANAGEMENT FRAMEWORK

### Section 1 — Tech Debt Inventory & Discovery

Establish the systematic process for identifying and cataloging all technical debt. Define the discovery channels: developer friction logs where every engineer records moments where the codebase slows them down or causes confusion during a two-week observation period, incident post-mortems that identify architectural or code quality factors that contributed to outages, code analysis metrics from tools like [TOOL: SonarQube / CodeClimate / Codacy / custom scripts] that flag complexity hotspots, duplication, outdated dependencies, and test coverage gaps, sprint retrospectives where the team identifies recurring technical obstacles, new hire onboarding feedback that highlights areas where the codebase is particularly confusing or poorly documented, and dependency audits that identify outdated libraries with known vulnerabilities or end-of-life runtimes. Create the tech debt inventory template with these fields for each item: unique identifier (TD-001), title in one sentence, description of the current state and why it is problematic, category from [CATEGORIES: code quality / architecture / dependencies / testing / documentation / infrastructure / security / performance / tooling], affected components listing the specific services, modules, or files impacted, symptoms describing the observable impact on developer velocity, system reliability, or user experience, and estimated remediation effort in t-shirt sizes (S: under 2 days, M: 2-5 days, L: 1-2 weeks, XL: 2-4 weeks, XXL: over 1 month). Conduct the initial inventory sprint: dedicate [TIME: 2-3 hours] of team time to a collaborative session where every engineer contributes their known tech debt items, then deduplicate, merge related items, and validate the list as a group.

### Section 2 — Scoring & Prioritization Matrix

Build the quantitative scoring system that removes subjectivity from prioritization decisions. Score each tech debt item on four dimensions using a 1-5 scale. Dimension one is Impact on Developer Velocity: score 1 means no noticeable impact on daily development speed, score 3 means developers regularly work around this issue spending 10-30 minutes per week, and score 5 means this issue blocks or significantly slows multiple developers every day. Dimension two is Risk to System Reliability: score 1 means no incidents caused by or related to this debt in the past year, score 3 means this debt contributed to 1-2 minor incidents in the past quarter, and score 5 means this debt directly caused a major outage or poses imminent risk of one. Dimension three is Compounding Rate: score 1 means this debt is stable and will not get worse if left unaddressed, score 3 means this debt grows moderately as new features are built on top of it, and score 5 means every sprint of new work makes this debt significantly harder and more expensive to address. Dimension four is Remediation Cost: score inversely where 1 represents XXL effort over one month, 3 represents M effort of 2-5 days, and 5 represents S effort under 2 days — this rewards quick wins. Calculate the priority score as: (Impact times 0.3) plus (Risk times 0.3) plus (Compounding times 0.25) plus (InvertedCost times 0.15). This weighting emphasizes velocity and reliability impact while rewarding items that will get worse if delayed and items that can be resolved quickly. Sort all items by priority score and divide into tiers: Tier 1 (score above 4.0) should be addressed in the next 1-2 sprints, Tier 2 (score 3.0-4.0) should be planned for the next quarter, Tier 3 (score 2.0-3.0) should be addressed opportunistically when working in affected areas, and Tier 4 (score below 2.0) should be monitored but not actively scheduled. Review and re-score the inventory quarterly as conditions change.

### Section 3 — Sprint Integration Strategy

Define how tech debt work coexists with feature development in sprint planning. Establish the capacity allocation model: reserve [PERCENTAGE: 15-25]% of each sprint's capacity for tech debt work, with the exact percentage adjusted based on the current severity level and upcoming feature deadlines. In practice, this means that in a two-week sprint with [CAPACITY: 40-60] story points of capacity, [POINTS: 6-15] points are allocated to tech debt items. Define three integration patterns for scheduling tech debt work. Pattern one is the dedicated allocation where tech debt points are planned alongside feature work in every sprint, with specific tech debt items selected from the prioritized backlog during sprint planning. Pattern two is the boy scout rule where developers are expected to improve any tech debt they encounter while working on feature tasks, with 10-15% buffer added to feature estimates to account for incremental improvements — this handles Tier 3 and Tier 4 items naturally. Pattern three is the tech debt sprint where every [FREQUENCY: 4th / 6th / 8th] sprint is dedicated entirely to tech debt remediation, attacking Tier 1 and Tier 2 items that require focused effort without the context-switching of mixed sprints. Choose the pattern or combination that fits your team's rhythm and stakeholder expectations. Define the sprint planning ceremony additions: review the tech debt backlog after feature planning to select items that align with the sprint's feature work (fixing debt in modules that are already being modified reduces context-switching), assign tech debt items to specific engineers who are familiar with the affected code, and set clear acceptance criteria for each tech debt item including the specific metrics that should improve after remediation.

### Section 4 — ROI Calculation & Business Communication

Build the ROI framework that justifies tech debt investment to non-technical stakeholders. Quantify the cost of inaction using these metrics: developer hours lost per sprint due to workarounds, slow builds, flaky tests, or unclear code — multiply by the fully-loaded hourly cost of an engineer to get a dollar figure, incident costs including engineering hours for investigation and remediation, customer impact costs (refunds, churn, SLA penalties), and reputation costs, feature delivery slowdown as a percentage — compare the team's velocity over the past four quarters to identify declining trends correlated with growing debt, and hiring and retention risk — senior engineers leave teams drowning in tech debt, and the cost of replacing a senior engineer is [COST: 6-12 months of salary]. Calculate the expected return on remediation: estimate the time savings per sprint after the fix (e.g., fixing the flaky test suite saves 3 hours of developer time per sprint), multiply by the number of sprints over the planning horizon (typically 12 months), and compare to the one-time remediation cost. Present the results using this template: "Investing [X] engineering days to [REMEDIATION DESCRIPTION] will save [Y] engineering hours per month, equivalent to [$Z] per year. Additionally, it will reduce [INCIDENT TYPE] incidents by approximately [PERCENTAGE]% and improve feature delivery velocity by [PERCENTAGE]%. The break-even point is [TIMEFRAME]." Create a quarterly tech debt report for leadership with these sections: current tech debt inventory summary with total items by severity tier, items completed this quarter with measured impact, items planned for next quarter with expected ROI, and trending metrics (velocity, incident rate, deployment frequency, lead time for changes) showing the correlation between tech debt remediation and delivery improvement.

### Section 5 — Execution Patterns & Best Practices

Define the execution patterns that make tech debt work successful. The strangler fig pattern gradually replaces a legacy system by building new functionality alongside it, routing traffic to the new implementation incrementally, and decommissioning old components only after the new ones are proven in production. This pattern is ideal for large architectural migrations with [TIMELINE: 3-12 months] execution horizons. The parallel run pattern operates both old and new implementations simultaneously, comparing outputs to verify correctness before cutting over. This is essential for data pipeline migrations and algorithm replacements where correctness must be verified with real production data. The feature flag pattern wraps the new implementation behind a feature flag, enabling gradual rollout to increasing percentages of traffic with instant rollback capability. Use this for any change that carries risk of regression. The boy scout pattern requires no dedicated planning — engineers improve code quality incrementally in every PR by renaming unclear variables, extracting helper functions, adding missing tests, updating outdated comments, and removing dead code. Set the expectation that every PR should leave the codebase slightly better than it was found. The timebox pattern allocates a fixed time budget to a tech debt investigation: spend no more than [TIME: 2-4 hours] determining the scope and approach, then present the findings to the team for a go or no-go decision before investing more time. This prevents rabbit holes where engineers spend weeks on a remediation that turns out to be more complex than expected. Define the anti-patterns to avoid: the big bang rewrite that replaces an entire system at once with months of work and no incremental value delivery, the gold plating approach that turns a targeted remediation into a complete redesign of tangentially related systems, and the invisible work approach where tech debt is done secretly without stakeholder communication, eroding trust and budget.

### Section 6 — Tracking, Metrics & Continuous Improvement

Establish the measurement system that tracks tech debt trends over time. Define the primary metrics: tech debt ratio calculated as the number of open tech debt items divided by total backlog items (target: below [RATIO: 15-25]%), mean time to remediate for completed tech debt items tracking whether items are getting harder or easier to fix, debt introduction rate measured as new tech debt items created per sprint versus items resolved, and developer experience score collected through a quarterly anonymous survey asking engineers to rate the codebase health on a 1-10 scale across [NUMBER: 5-8] dimensions (build speed, test reliability, code clarity, documentation quality, deployment confidence, debugging ease, onboarding experience, dependency health). Build the tracking dashboard using [TOOL: Jira / Linear / Notion / custom dashboard] that displays the current inventory by tier and category, the burndown of Tier 1 items over time, the trend of developer velocity correlated with tech debt remediation, and the incident rate correlated with outstanding reliability-related debt. Conduct the quarterly tech debt review ceremony: review the inventory for accuracy (close resolved items, add newly discovered items), re-score items whose context has changed, adjust the capacity allocation percentage based on the current severity assessment, celebrate completed remediation work and its measured impact, and set goals for the next quarter. Define the continuous improvement loop: every sprint retrospective includes a tech debt check-in question, every post-mortem identifies tech debt contributing factors, every quarterly review adjusts the strategy based on measured outcomes, and every annual planning cycle sets the tech debt budget based on the trending metrics.