A tale as old as time – the engineering team is racing against the clock, developing features with the understanding that certain aspects will be “fixed or improved upon” later. These well-intentioned @todo comments and tech debt markers accumulate over time, sidelined in favor of immediate goals. Then, as new technologies make parts of the codebase obsolete or as the realities of the Software Development Life Cycle (SDLC) reveal new priorities, these tasks inevitably get deprioritized. Before long, this neglected tech debt grows, sometimes lurking silently until it leads to an emergency—a dreaded Sev1 outage that demands immediate attention. What do we do with the ever-mounting tech debt? How do we set up the team for success as they continue down the SDLC for a given product?
Document Your Tech Debts
Every engineer has areas in the code that they wish they could improve. The changes can be sparked by newfound knowledge of the tech stack or a tight deadline, causing corners to be cut; whatever the reason, we all have ideas and pain points we experience as we work on each project. It is easy to bury those ideas and pain points; however, in the team’s best interests, it is important to jot that down for the team’s visibility. The ideas don’t need to be fully fleshed out in the initial documenting phase. Each contributor on the team should be empowered to propose new ideas to be discussed.
Prioritize Your Tech Debts
Now we have a list of tech debts, where do we even start?
Similar to the sprint process, the team should groom and size tech debt. The difference is that the contributors will have a lot more power in determining the priority of each tech debt item.
Take a page of the the sprint process to determine the priority, we can use a form of the RICE (Reach, Impact, Confidence, Effort) or ICE (Impact, Confidence, Effort) method to determine the priority of an item. Adopting the prioritization metrics for tech debt we get the PICE (Painscale, Impact, Confidence, Effort) priority metric.
- Pain Scale
- Scale: 1 to 10
- Question: How much pain does this issue cause the team?
- Purpose: If this issue scores high on the pain scale, it should be assigned a higher priority automatically.
- Scale: 1 to 10
- Question: What is the potential impact of resolving this tech debt?
- Considerations: Is it a minor change (like adjusting website spacing) or a major one (such as reworking backend infrastructure)?
- Purpose: Impact should be a primary factor when prioritizing tech debt items.
- Scale: 1 to 5
- Question: How confident are we that the solution will resolve the tech debt?
- Estimation: Note that the confidence score is flipped 1 being the highest confidence 5 being the loweset
- Considerations: Are we working with a new technology, or is this a routine fix that hasn’t been addressed yet?
- Purpose: A lower confidence rating may indicate the need for additional time and resources.
- Scale: 1 to 10
- Question: How much effort will it take to resolve this tech debt?
- Estimation: Can be based on Fibonacci sprint points or a simple 1-10 scale.
- Purpose: This score provides an estimate of the work required to complete the fix.
Example
| Issue | Description | Pain Scale | Impact | Confidence | Effort | Total Score |
|---|---|---|---|---|---|---|
| Secret Keys found in GIT Repositories | Developer secret keys were accidentally added to the GIT repository. Remove the key from repo and rotate keys | 10 | 10 | 1 | 1 | 100 |
| Normalizing Database | Our database is starting become tangled. We would like to spend some effort on normalizing the db. | 5 | 5 | 2 | 3 | 16.67 |
| Home page footer padding | On our Home page the home page footer padding is off by 2px | 1 | 1 | 1 | 1 | 1 |
As we can see here, based on the formula, the team can systematically triage the tech debt.
Now that we have discussed prioritizing our tech debt, we will cover how to incorporate this into the sprint processes in the future post.
PM Perspective 
Leave a comment