Why You Shouldn't Point Tech Debt

Let's suppose we have a team that does 20 points of work per sprint, but a tenth of that work (2 points) would wind up as technical debt. So, if our hypothetical team wanted to accumulate no debt, they could deliver 18 points of business value, paying off the two points of potential debt, just like paying off your credit card in full at the end of each month.

We could also have our hypothetical team deliver the full sprint of work toward business value and choose to carry the debt into the next sprint. (Of course, we will ultimately fall somewhere between the two hypotheticals, paying down debt as the opportunity arises, carrying it when the friction it causes is relatively less than the business value being delivered. Humor me, though.) So with the first sprint we deliver 20 points and carry two points of debt into the next sprint. The thing we know about debt is that it comes with a price, interest charges! For the sake of argument, let's say our team is paying Lucky Luciano type rates on their interest so that every two points of debt costs us a point of work each sprint due to the friction it causes.

(Tech debt is like sand in the gears of your development process. It will cause things to move slower and slower until development grinds to a halt completely. Of course it works slowly over time, and the interest you pay on it is much lower than 50% per sprint. However, a system of any size that has been around for any length of time has accumulated much more than a tenth of a sprint's worth of debt. Your dev. team could probably work a couple months right now on nothing but technical debt.)

But back to our hypothetical --

So now, in the second sprint, our team can accomplish 19 points of value and accumulate two more points of debt. In the third sprint they are going to do 18 points, just as if they had been paying the debt with each sprint, but now they are six points worth of debt. Of course, in the fourth sprint the debt has caught up on our team: They begin doing less as if they had been paying it off with each sprint, and it will spiral down from there.

When this becomes a big deal is when the business comes to the team and says they would like to add 90 more points to the system and wants the team to estimate how long that work will take. In the first scenario the team can relatively confidently say the work will take exactly five sprints. (Amazing how that worked out to be exactly divisible by 18!) In the second scenario the estimate would depend on where the team was with their debt. A completely greenfield solution would take five sprints, yes, with an accumulated debt of about another half a sprint. If the team couldn't start greenfield, though, it could be six, seven, eight... sprints. While in the first scenario, it would be five sprints regardless of what point the team began developing.

So comparing the team to itself in the two separate scenarios (because we'd never compare velocity of different teams as apples-to-apples, right?), it is not accurate nor fair to say they are delivering the same amount of value in both cases. With an effort lasting fewer than five sprints they will deliver more in the second scenario, delivering value and accumulating debt. More than five sprints and they deliver more by paying down debt every time.

Now suppose another scenario where our team has accumulated 20 points worth of tech debt. Rather than deliver only ten points of value with the next sprint, they choose to take the hit and pay off the debt, delivering no business value. On the next sprint, however, they are back to delivering 18 points of value (accounting, once again, for immediately taking care of any debt). After the third sprint they've delivered 36 points of value compared to what would only be 27 if they continued stumbling carrying the debt. We can measure the difference in value, nine points after 3 sprints, being delivered by the decision to pay off the debt. If we measure debt and business value the same way, that comparison won't be made. It isn't that the comparison can't be made -- And I realized that as I wrote this post. With some bending over backwards while jumping through hoops and some algorithms written in python, comparisons using tech debt pointed as stories could be made. In my next post, though, I will argue why a comparison like that probably won't be made and shouldn't be made.