The ReleaseTEAM Blog: Here's what you need to know...

Tackling Technical Debt Series Part 3: Prioritizing Technical Debt

Welcome back to our blog series, “Tackling Technical Debt.” In Part 1, we discussed the different categories of technical debt you may encounter in various projects. We then covered a couple of scenarios that show taking on technical debt can be a strategic decision that helps the business in Part 2. In this third post, we will help you create a plan for tackling existing technical debt.

Over time, software development projects can accrue technical debt through intentional and unintentional choices. When teams intentionally choose technical debt, they make a plan to address it later when they have more time, more resources, or more funding. Unfortunately, these tasks are not always well tracked or get delayed for more urgent requests. The growing list of technical debt tasks becomes more daunting to resolve. How do development teams and business leader prioritize which technical debt to fix first? The answer lies in a modification of the time management matrix first popularized by President Eisenhower.

What is the Eisenhower Matrix?

It’s a system for prioritizing tasks into four quadrants based on their urgency and importance:

Product Managers and software teams use a variation of this matrix by renaming the axes to “Value” and “Difficulty” to rank feature requests:

This same matrix is also useful for prioritizing technical debt by ranking each task by its value and level of effort to fix. This can be tracked in software, or your team can use a whiteboard and sticky notes to move tasks around.

Defining Value

Software teams can determine the value of fixing specific technical debts by asking these questions:

Is it critical to fix now because it is breaking the system? These will rank higher in value.
Is it a barrier to a business need like scalability or urgent feature requests? These will rank high in value but lower than the critical fixes.
Is it a nice-to-have or simply old technology but not tied to a business need? These will rank lower in value.

Ranking Difficulty

Most teams will already have a ballpark idea of how easy or difficult fixing specific technical debt, so use this axis to rank the effort of each task. These questions can help teams determine the difficulty:

Is it limited to a specific class or function? These will be easier to solve.
Is it limited to a specific application or owned by one team? These take a bit longer, but the payoff will make future changes easier to implement.
Is it systemic across multiple applications, the architecture, or require buy-in and work from multiple project teams? These can be the most difficult to resolve but ignoring them for too long will turn them into critical issues.

The Path Forward

Move forward with execution after technical debt tasks are placed on the matrix. Critical tasks that are easy to fix will be done first, while very valuable fixes that are more difficult to do will be started but take longer to complete.

Software teams might be able to solve items in the lower left quadrant (easier, less valuable) alongside a related feature update or when the urgent tasks are completed. Whenever your team encounters new technical debt, rank it against the existing debt to see if it’s more urgent or more valuable to fix. This continuous cycle will help software teams re-prioritize tasks as new information becomes available.

This is Part 3 in a 4-part series on Managing Technical Debt.

← Tackling Technical Debt Series Part 2: Taking on Tactical Technical Debt Tackling Technical Debt Series Part 4: Reducing Technical Debt with Automation →

Let's Talk DevOps!

Call: (866)-887-0489
Email: info@releaseteam.com