Technical debt prioritization for growing software teams
Prioritize technical debt by tracing the changes and operational work it affects. Compare evidence of coupling, dependency exposure and recurring toil, then agree which bounded repair or investigation deserves capacity. Record the owner, completion evidence and condition that would cause you to revisit the decision.
The short version
- Start with a consequence. Link each candidate to observed work and a customer or operating impact.
- Compare consistent evidence. The workbook reviews three candidates across four evidence areas.
- Plan a bounded repair. Include verification, migration and maintenance responsibility.
- Keep a decision record. Choose Address, Investigate or Defer with trigger and name the accountable owner.
Watch Episode 2: The Technical Debt Trap
Watch: The Technical Debt Trap
The video introduces coupling, dependency health and planned refactoring. Use the article and workbook to test those concerns against your own evidence; the video statistics and fixed sprint allocation are not validated requirements.
Get the companion workbook ↓Start technical debt prioritization with a consequence
Technical debt prioritization starts with a specific change or operational consequence that you can inspect. Describe the affected workflow, attach evidence of the obstruction and name the person accountable for its cost. Review coupling, dependency health, recurring toil and capacity together before choosing which debt candidate deserves action.
A request to clean up the codebase leaves a product leader with little to compare against a customer commitment. A request to isolate an invoice calculation because routine billing changes require coordinated edits gives the review a boundary. Record the next planned change, the services it touches and the failure that would matter to customers. Keep cosmetic preferences separate from observed constraints.
The Software Engineering Institute describes data-driven debt analysis using defects, change and bug churn to locate code that requires attention. Use that approach to assemble evidence from your own repository. A busy module is a lead for investigation; explain whether activity comes from healthy product development or repeated repair before calling it expensive debt.
Choose an observation window and record its limitations. A release freeze, an unusual migration or incomplete incident records can distort the picture. Ask the product owner to confirm which upcoming capability depends on the area. When reviewing software moving from an initial build into production, include operational tasks that never appeared in the original feature estimate.
Keep a separate route for urgent incidents and security response. A debt review should inform those processes, while the incident owner retains authority to contain an active problem.
Compare three candidates with the same evidence
Select three debt candidates and describe each using the same evidence fields: affected work, observed consequence, proposed change and remaining uncertainty. Keep actual measurements separate from estimates. A short comparison makes the decision discussable without presenting an invented score as an objective ranking of engineering risk.
Give each candidate an owner who can retrieve the underlying tickets or change records. Record the affected user journey, the next foreseeable exposure and the cost of postponement in plain language. If the cost is unknown, name the missing evidence and the smallest investigation that could resolve it. Do not replace that gap with a confident numerical rating.
| Question | Evidence to attach | Decision use |
|---|---|---|
| What work is affected? | Change and incident identifiers | Identify the relevant workflow |
| What consequence occurred? | Observed delay, rework or failure | Separate observation from prediction |
| What would change? | Bounded repair and rollback plan | Compare feasible interventions |
| What remains uncertain? | Unknown with investigation owner | Choose action or further evidence |
A clearly fictional example: a team compares a shared billing module, an ageing document library and a manual account reconciliation script. The billing candidate has linked rework tickets; the library has an unresolved applicability question; the script has a repeatable operator log. Those differences justify different next steps even before anyone estimates savings.
Allow the review to conclude that none is ready for a large repair. A named investigation can be the most useful commitment when the proposed solution is broader than the demonstrated problem.
Find the boundary that makes changes travel
Investigate coupling by following a real change across code, tests, deployment and team ownership. Record which dependencies require coordination and why. Prefer a repair that removes an observed constraint, with an explicit compatibility and rollback plan, over choosing an architectural pattern before understanding the dependency.
DORA describes loosely coupled teams through outcomes such as independent testing and release. Turn those outcomes into questions for the affected workflow. Can a team validate its change without waiting for another team's environment? Does a database migration force both services to ship together? Does a shared configuration silently change behavior elsewhere?
Draw the path from the initiating change to the last required approval. Mark the owner of each interface and distinguish technical dependency from policy dependency. Extracting a service will not resolve a queue caused by an unavailable approver. Conversely, clearer team ownership will not remove a shared schema that makes incompatible releases unsafe.
Use Google guidance on small, coherent changes when planning the repair. Identify a slice that can be reviewed on its own, how old and new callers coexist and when compatibility code can be removed. The final deletion needs an owner too. Otherwise an attempted decoupling can leave another permanent transition layer.
For systems that need reliable production operation, include observability in the boundary. Decide which signals show that the change behaves correctly and who can stop the rollout. Define success as the specific coordination step removed, alongside evidence that the customer behavior still works.
Review dependency health and actual exposure
Assess dependencies using the deployed component, its version, the path that uses it and the available maintenance evidence. Treat repository signals and vulnerability findings as investigation inputs. Prioritize an identified exposure with the security owner, and document a tested update, replacement or containment path.
OpenSSF Scorecard checks include maintenance and dependency update signals. Read the finding behind a signal. An update bot can exist while its pull requests remain unreviewed. A repository with little recent activity may need a different interpretation from a rapidly changing integration that no longer supports your deployed version.
OWASP Dependency-Check can help identify components associated with known vulnerabilities. Confirm the identity and applicability of a result before creating a migration project. Record where the dependency runs, whether vulnerable behavior is reachable and what controls currently limit exposure. An absence of known findings does not establish that the component is safe or suitable.
CISA recommends its known exploited vulnerabilities catalog as an input to vulnerability prioritization. Use that evidence with business exposure and your security process. Avoid copying catalog totals into a decision record that will soon be stale. Preserve the advisory reference and the reviewed component version instead.
Ask the proposed repair owner for compatibility tests, migration effort and fallback limits. A replacement may affect stored data or customer integrations as well as application code. If external help is needed, use a structured supplier evaluation to check who will maintain the result and who owns the upgrade path after the initial engagement.
Measure recurring toil without promising automatic savings
Log recurring operational work as observed events with a trigger, operator, duration and outcome. Check whether the work is repetitive and can be removed safely. Compare a proposed automation with its implementation and maintenance effort, including exception handling and the manual fallback that must remain available.
Google SRE characterizes toil as manual, repetitive operational work that lacks lasting value and can be automated. Use the definition to examine tasks such as repairing imports or reconciling account state. Avoid treating all operational work as debt. Incident learning and a necessary customer exception may deserve attention without being candidates for automation.
Ask operators to record actual occurrences during the chosen observation window. Include the time spent recognizing the problem, obtaining access and checking the result. Separate hands-on effort from elapsed waiting. Note missing records, concurrent tasks and rare exceptions so the estimate does not imply more precision than the log supports.
Then specify what an intervention removes. A script that executes a manual action may still leave an operator to detect the issue, approve the change and handle failures. Put those remaining steps into the proposal. Record the person who will maintain credentials, update the automation and test recovery when an upstream interface changes.
When comparing internal and external engineering ownership, assign the ongoing operational responsibility explicitly. A handover document is useful only if someone can execute the fallback with the access available to them. Test an exception as part of the repair before counting the recurring task as removed.
Plan capacity around evidence and commitments
Choose debt capacity from the work you can justify and the people available to complete it. State which product commitment changes when a repair enters the plan. Use effort ranges and explicit assumptions, then revisit the allocation when incidents, discoveries or customer needs change the evidence.
A fixed maintenance percentage cannot explain which repair should happen next or whether the team can complete it safely. Start with named work and the necessary skills. Include investigation, implementation, verification and migration support in the estimate. Record whether specialist review or a shared environment creates a scheduling constraint.
Ask the product owner to compare the consequence of delay with the cost of changing the current commitment. Sometimes the sensible response is a small compatibility improvement inside an already planned feature. Other cases justify a separate repair, particularly when urgent exposure or repeated operational work changes the delivery assumptions.
Use Google code review guidance to include design, complexity and appropriate testing in the completion criteria. A pull request merged into the repository may be only part of the job. Callers may still need migration, operators may need an updated runbook and old behavior may need removal after a safe transition.
Keep capacity decisions visible in the same planning discussion as feature work. If a repair depends on custom software engineering support, specify the bounded outcome and internal owner before requesting an estimate. Compare the proposal with the team's remaining review and integration capacity, not just the availability of additional developers.
Define a repair you can verify and reverse
Write the intervention as a bounded change with a baseline, an observable outcome and a stop condition. Agree how the owner will verify it against comparable work. Include migration and rollback limits so a broad improvement proposal cannot expand indefinitely under the label of technical debt.
For a coupling repair, the outcome could be a demonstrated independent test path for the affected change. For a dependency update, it could be removal of the reviewed vulnerable version from the deployed inventory with compatibility evidence. For toil, it could be a logged run through the automated path and its exception handling. Choose the outcome that follows from the original consequence.
Record the evidence available before implementation and the evidence expected afterward. Compare like work where possible, and note other changes that could affect the result. A quieter support week does not establish that an automation solved every recurring incident. A successful deployment does not establish that a hidden compatibility obligation has disappeared.
In the fictional billing example, the team could isolate one calculation interface and test existing consumers before changing the rest of the module. The owner would record whether a representative change still requires coordinated edits. If the dependency persists for another reason, the review can adjust the hypothesis without authorizing a wider rewrite automatically.
Set the stop condition before work begins. Escalate if a migration requires unplanned customer downtime, the effort range changes materially or the repair reveals a different risk. Capture the new evidence and ask the decision owner to authorize the revised boundary.
Record the decision and its revisit trigger
Close the review with Address, Investigate or Defer with trigger for each candidate, and assign one accountable decision owner. Preserve the evidence, assumptions and next review condition. The workbook is a practical review method for this discussion; its counts and prompts are not a validated risk score.
For Address, name the delivery owner, agreed capacity, completion evidence and rollback responsibility. For Investigate, specify the unanswered question and the artifact the investigator must return. For Defer with trigger, write the event that would change the decision, such as a planned migration, a new advisory or another observed failure of the same path.
Do not let a review date become the only trigger. A condition tied to actual exposure can prompt action before the next planning meeting. Conversely, repeated calendar reviews without new evidence consume attention while leaving the same uncertainty unresolved. Assign someone to watch the condition and identify where they will record a change.
The workbook covers four evidence areas: coupling, dependency health, recurring toil and capacity planning. It compares three debt candidates and closes with one accountable decision record. These are the resource's structure, not industry benchmarks or recommended allocation targets. Use actual values and attach evidence links that another reviewer can inspect.
Keep the completed record with the relevant product and engineering work. When the intervention ends, return to the original consequence, document what changed and leave any unresolved exposure with a named owner. That record gives the next planning discussion a concrete starting point.
Technical debt prioritization workbook
Compare observed debt consequences, evidence and delivery capacity before recording an accountable decision.
Fillable PDF · 9 pages · Save a copy for each review
Download the workbook
Enter your details for immediate access.
Your workbook is ready.
Open the fillable PDF and save a copy for your review. The delivery status above tells you whether your email was accepted for sending.
Download the workbookThis download link is valid for 7 days.
Technical debt prioritization questions
What should technical debt prioritization measure?
Should every sprint reserve a fixed amount for debt?
How do we compare debt when evidence is incomplete?
Does technical debt require an architectural rewrite?
Who should own the decision?
How do I download the workbook?
Sources
- CMU Software Engineering Institute, Managing Technical Debt with Data-Driven Analysis. Rank observed technical debt using defects, change churn and causal analysis.
- Google Engineering Practices, Small CLs. Small coherent changes improve review and simplify reasoning about change risk.
- Google Engineering Practices, What to look for in a code review. Review design, complexity and tests to assess maintainability and safe changes.
- OpenSSF, Scorecard checks. Repository maintenance and dependency update tooling are signals that need context.
- OWASP, Dependency-Check. Software composition analysis can identify known vulnerable dependency components.
- CISA, Known Exploited Vulnerabilities Catalog. Known exploitation is an input to vulnerability remediation priorities.
- DORA, Loosely coupled teams. Independent testing and deployment are useful outcomes when assessing coupling.
- Google SRE, Eliminating Toil. Recurring manual operational work can consume capacity without producing lasting improvement.
