A Practical Prioritization Approach for Technical Debt
In Job interviews, one of the most frequent questions I get is — “Assume you have new feature requests from business, but your technical team wants to fix the technical debts first, what do you do?”.
Well, it is logical for the interviewer to assume that as a product owner, you will have a ready answer for this. Because every PO faces this dilemma on a regular basis. The conflict between launching new features versus improving the code quality is real and never ending. However, I believe there is no right or wrong answer to this question. It does not matter ‘what’ you prioritize — what matters is how you approach the problem and ‘how’ you prioritize.
But lets not jump the gun. Before we get to the approach, lets look at the two different types of Technical debts that may come your way. These are by no means industry terms, but you should be able to broadly define technical debts into these two logical categories —
1. The ‘Deliberate Tech Debts’
Imagine a scenario — ‘You are supposed to deliver a new feature by the end of the sprint. And sometime during the sprint, the development team realizes that if we want to implement it the correct way - ensuring engineering best practices, it will overspill and is not feasible to complete in the earlier planned timelines.’
Sounds familiar? Well, this happens a little too often in most product development teams, and at this time the PO is left with the choice of either delaying the go-live of the feature (which sometimes is just a quick FYI to stakeholders, however other times it involves massive alignment and discussions due to the impact) OR to create what I call a ‘Deliberate Tech Debt’ i.e. write crappy code, ship out the feature on time, and deal with the consequences later.
To be honest, there is nothing wrong in this approach of creating a deliberate tech debt — when really needed. However, what ends up happening a lot of the time is, product teams lose track of these ‘Deliberate Tech Debts’, and start accepting them as design/engineering decisions. This eventually hinders with the growth of the product, as these become the next category of debts i.e. the Accidental tech debts.
2. The ‘Accidental Tech Debts’
Now these types of tech debts are at times a genuine area of concern. These are tech debts which arise from actual bad coding practice, bad/not scalable architecture design, incomplete requirements, half baked test, etc. In short — these are the debts created because of the mistakes the product team makes.
Most of the time, these debts reveal themselves at the worst possible moments. Just when you are chasing a really tight timeline for a super important feature — voila! Tech debt is waiting just around the corner to derail your plans. Its breaks your heart when the development team comes up and says “we need to refactor the code to build this feature, else it will not work”.
So is it wrong to have these tech debts? Yes and No. If the these accidental tech debts keep arising again and again, and you start to notice that every other sprint has a couple of tech debt stories in scope — this is wrong and is a problem to resolve. However, if the product team is prudent enough to learn from the tech debts and focus on building more scalable code base, these are not a major cause of concern.
But what is important to understand is — Accidental tech debts are inevitable. You can always reduce the number by being very diligent and proactive, but eventually as technology progresses, some parts of your code will become outdated (software entropy) and a debt.
So now to the major question — As a Product Owner, how do should we tackle and prioritize tech debts?
The answer lies in the type of tech debt you are tackling.
1. Plan the release schedule for ‘Deliberate Tech Debt’ Backlog
For known or ‘Deliberate tech debts’, the best approach is to plan the backlog. Create a separate EPIC to track all the tech debts, and ensure a ticket/story is captured as soon as the decision to proceed with the debt is taken — so as to not miss it.
If you have a huge tech debt backlog, reserve at least 15% of your sprint capacity towards fixing them gradually, and every 3–4 sprints, keep one sprint dedicated to fixing the tech debts.
Essentially, the trick is to treat ‘deliberate technical debt’ like actual financial debt.
When you have a lot of financial debts, the smartest way is to lower your investments and pay back the debt first — because the interest charges are generally higher than the investment returns. Similarly, for deliberate tech debts, the best approach is to reduce it and get rid of it as soon as possible — while not impacting any urgent business needs.
2. Decision tree for ‘Accidental Tech Debts’
Accidental or unplanned or unknown (however you may want to call them) tech debts need to be handled differently. These are time sensitive, you cannot plan ahead for them, and the decision on resource allocation needs to be taken keeping into consideration a lot of parameters.
So my go to solution is to first pass the tech debt via the ‘Tech debt decision tree’. Only if the tech debt passed through all the criteria, does it qualify for a higher priority and immediate attention in the current sprint. Otherwise, I would park this newly revealed debt into the tech debt backlog and resolve it in a planned fashion.
I hope the above methodology helps you to manage technical debts better and have better negotiations and reasoning with the development team, as to why at times fixing the code quality is planned for later.
And as usual, hit me up for any kind of discussions or thought exchange via LinkedIn — https://www.linkedin.com/in/vishsoni/
