organizationL2 GuidedTech Debt & Modernization

Debt categorized and prioritized

Debt categorized and prioritized is the L2 state where an organization has moved from informal awareness of technical debt to a structured system for tracking, classifying, and ordering debt items.

·Tech debt is categorized and prioritized (severity, impact, effort)
·At least one manual migration attempt has been completed or is in progress
·OpenRewrite or equivalent automated refactoring tool has been evaluated or adopted for basic recipes

·Tech debt reduction is allocated time in sprint planning (even if small)
·Migration attempts are documented with lessons learned

Evidence

·Categorized tech debt backlog with priority ratings
·Completed or in-progress migration project documentation
·OpenRewrite configuration or evaluation report

What It Is

Debt categorized and prioritized is the L2 state where an organization has moved from informal awareness of technical debt to a structured system for tracking, classifying, and ordering debt items. Instead of a vague shared understanding that "the authentication module is a mess," the team has a documented debt inventory where each item has a category, a severity, and a priority ranking that determines what gets addressed and when.

The categorization step is the foundation. Debt falls into several distinct types, and each type has different remediation strategies and different business urgencies. Security debt - outdated dependencies with known CVEs, deprecated authentication patterns, unencrypted data at rest - is the most urgent because it has direct risk implications. Architectural debt - inappropriate coupling, violated domain boundaries, patterns that no longer match the current system's needs - is the most expensive because it makes every feature in the affected area more costly. Test debt - missing coverage, unreliable tests, tests that verify implementation rather than behavior - directly impacts deployment confidence. Documentation debt limits knowledge transfer and onboarding. Identifying which type of debt each item represents determines who addresses it and how.

The prioritization step translates the inventory into a work queue. Prioritization criteria typically include urgency (does this debt have a deadline, such as an end-of-life dependency?), impact (how many developers does this slow down, how frequently?), remediation cost (how much work is required to address it?), and risk (what is the worst-case consequence if this debt is not addressed?). A simple scoring matrix across these dimensions produces a prioritized list that is more defensible and more useful than pure gut feel.

At L2, the debt inventory is a living document rather than a one-time audit. New debt is added as it is created or discovered. Items are removed when addressed. Priority scores are reviewed quarterly. The inventory becomes the basis for planning: debt reduction work is selected from the top of the priority list rather than chosen ad hoc.

Why It Matters

Converts invisible costs to visible decisions - A categorized and prioritized debt inventory makes the cost of deferral explicit; when a security debt item sits at the top of the list for two quarters, that is a documented decision with documented risk, not an oversight
Enables systematic remediation - Items in the same category can be addressed together using the same tools and patterns; categorization enables batch remediation rather than one-off fixes
Creates a shared language for debt conversations - When debt has names, categories, and scores, conversations about tradeoffs become more precise; "this is P1 security debt" is a more actionable statement than "this code is a mess"
Sets up AI automation - A well-maintained debt inventory at L2 is the input queue for AI-assisted remediation at L3; agents need a structured list of items to work from
Demonstrates organizational maturity to stakeholders - A debt registry with clear prioritization signals to executives and auditors that engineering is managing risk deliberately, not reactively

Getting Started

Establish debt categories - Define the categories your team will use: Security, Architectural, Test, Documentation, Dependency (version currency). Definitions should be crisp enough that any developer can classify a new item without ambiguity.
Run an initial inventory sprint - Spend one sprint with the whole team contributing to the debt inventory. Use the category definitions. Aim for 20-40 items that represent the most significant known debt, not an exhaustive list of every code smell.
Create a scoring rubric - Define scoring for urgency (1-3), impact (1-3), and remediation cost (inverse: expensive = lower score). Calculate a priority score: urgency x impact / cost. The formula can be adjusted, but a formula is better than pure ranking.
Select the top 5 items for the next quarter - Pick the five highest-priority items and add them to the sprint backlog for the next quarter. These are not optional "if there's time" items - they are committed work.
Add debt tracking to your definition of done - When a developer creates technical debt to meet a deadline, they create a debt inventory item at the same time. This stops the inventory from becoming stale and makes debt creation a deliberate, documented decision.
Review and re-score quarterly - Priority changes as the business changes. An item that was low urgency becomes urgent when its dependency reaches end-of-life. Schedule a quarterly debt review meeting to update scores and re-sequence the queue.

Tip

Do not let the perfect be the enemy of the good when building the initial inventory. A 30-item list with rough scores that is maintained is worth far more than a comprehensive 200-item list that is abandoned after the initial sprint.

6 steps to get from here to the next level

Common Pitfalls

Building the inventory once and never updating it. A static debt registry becomes incorrect within weeks as code changes, new debt is created, and old items are addressed. The inventory is only useful if it is maintained as a living document with clear ownership.

Scoring every item the same. If most items end up with similar priority scores, the scoring rubric is not discriminating enough. Good prioritization should produce a clear top 10% that the team agrees should be addressed next. If everything is high priority, nothing is.

Separating debt work from feature work. Teams that maintain debt backlogs but plan them in a separate process from feature work find that debt items never get done because they are never competing in the same sprint planning session. Debt items should be in the same backlog as features, selected by the same prioritization process.

Missing the security category. Many organizations build debt inventories focused on architectural or test debt and undercount security debt. Outdated dependencies with known CVEs are tech debt with an immediate risk profile. They should be tracked, scored, and addressed on the same cadence as other debt.

No single owner for the inventory. A debt inventory with no named owner becomes everyone's responsibility and no one's priority. Assign a single owner - typically the lead engineer or tech lead - who is accountable for the inventory being current and for debt items being addressed.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob has established that debt is a real cost and has the team's buy-in on addressing it. The problem now is that without a structured inventory, every sprint planning session involves a different set of developers advocating for different debt items based on their personal frustration. There is no shared view of what should be addressed next, and the selection process feels arbitrary.

The debt inventory solves this problem by making prioritization a structured process rather than a political one. Bob should run the initial inventory sprint himself or with his tech leads, establish the scoring rubric, and then present the top 10 items to the full team. The conversation shifts from "I think we should fix the authentication module" to "the authentication module is P1 security debt with a score of 9; the reporting module is P2 architectural debt with a score of 6; based on our capacity, we can address the authentication module this quarter." This is a more productive conversation, and it produces more defensible commitments to stakeholders.

SarahProductivity Lead

Sarah has been measuring velocity by area of the codebase and has the data that shows where debt is costing developer time. What she has been missing is the bridge between her productivity data and the engineering team's debt work - the debt inventory is that bridge. If the debt inventory includes the code areas that map to Sarah's slow-velocity zones, she can validate that the priority order makes sense (high-impact debt areas should be prioritized) and measure the productivity improvement when those items are addressed.

Sarah should request access to the debt inventory and add a column for "estimated velocity impact" - her data contribution to the scoring rubric. This makes the inventory more accurate and gives Sarah a direct line of sight from debt remediation work to productivity outcomes. When the authentication module debt is addressed and PR cycle time in that area drops by 30%, that is a measurable outcome that Sarah can report and that justifies the debt reduction investment.

VictorStaff Engineer - AI Champion

Victor has been the informal mental debt registry for years. He knows every item that should be on the list. The transition to a formal inventory is partly about moving his knowledge into a shared artifact and partly about adding rigor to the prioritization that has previously been his judgment call.

Victor should lead the initial inventory sprint and be the named owner of the inventory going forward. He should also use AI tools at this stage to accelerate categorization: given a codebase, an agent can scan for common debt indicators - outdated dependencies, missing test coverage, deprecated API usage, high cyclomatic complexity - and produce a candidate debt list that Victor reviews and refines. This is not full AI-assisted remediation; it is AI-assisted discovery, which is appropriate and effective at L2. The categorized inventory Victor produces is also the input that L3 AI remediation agents will need - building a clean inventory now is an investment in higher maturity levels.