Why You Shouldn't Point Tech Debt, Take 2

I want to expand on not pointing technical debt stories. As I finished the last blog post, I realized that I had made the presumption that teams should only assign story points to stories based on business value. Then I proceeded to basically lay out the argument for why a team should (or in some cases should not) pay down their technical debt, kind of skirting the entire question of what not assign points in the first place. A classic case of begging the question: We only point things that are valuable because they are things that are valuable. If you already have bought into that statement, you wouldn't be here asking the question of whether to point tech. debt or not.

So now I want to back the premise that a team should only point work that is of value to the business. One of the developers I support is a fan of both metaphors and the NBA, so I would like to present my argument in these terms: When you watch a basketball game rebounds, assists, steals, and turnovers are all very important to the teams. However, at the end of forty minutes, the one stat that matters is how many points each team scored. Just like having a lot of turnovers will hurt a team's chances to win, technical debt is going to drag down your development's ability to deliver new features. In the end, however, the business runs on the value of the features the team delivers.

I mentioned previously that a team may look to distinguish between technical debt points and business value and still somehow combine those to estimate output. I don't believe that this is really an apples-to-apples comparison, however. Some technical debt MUST be addressed and some subset MUST be addressed IMMEDIATELY (particularly if bugs and incidents fall into that technical debt bucket). For example, our organization recently moved its package management from a Nexus repository to Artifactory. Every development team had to change projects to point to Artifactory. No value was delivered to the customer, but this had to be done by a set deadline else project build pipelines would cease to work. We also have contractual obligations for SOC 2 and PCI compliance driven by hard deadlines. Managing API keys and updating network diagrams does not deliver value to our customers but must be done and must be done by particular dates. If that date is a couple years off the tradeoff with choosing to bring in business value may be relatively small. That cost increases, however, as the deadline approaches.

Another thing that makes estimations of technical debt unequal to estimating business value is that technical debt, in my opinion, is generally more difficult to accurately estimate. I say this because if it were easy to accurately assess the risk, effort, and value of paying down debt that teams would actively engage it rather than accumulating it. I believe technical debt accumulates, in most cases, precisely because we find it difficult to assess risk, effort and payoff. "If it were easy, we'd have done it." I know me saying this is my own opinion based on experience and that in some cases teams know exactly the risk and effort and the value simply isn't worth addressing the debt. That said, this is one more reason why, in my experience, I do not believe teams should point technical debt. To extend my metaphor further - a made basket in basketball is worth a set number of points: one for a free throw, two for a standard field goal, and three for those beyond the three point line. A steal, like paying off technical debt, may result in points, and it may not. A coach can't tell his team, "If you get this many steals we are sure to win the game." He can look Jimmy Chitwood in the eye though and say, "Jimmy, if you come off the picket fence and make this shot, we win the game." (That isn't exactly how it happens in "Hoosiers" and I realize I've taken this too far, but I can't get this far into a basketball metaphor and not bring up one of the greatest sports films ever made.)

A final reason why I do not see technical debt and business value estimates to be equivalent is that a team can timebox paying down technical debt. For user stories delivering business value there is some discrete level of effort involved in delivering that value. Generally a user story that is 80% done will deliver 0% of its value. (This in itself is probably another blog post regarding the INVEST model for writing user stories.) Paying down technical debt can be timeboxed, though. I could devote half of a sprint to moving my package management to Artifactory. That's not the same as being able to say how much I am delivering, only the time invested. Perhaps I will get two projects done, perhaps it will be ten - I know how long it will take and how much it is affecting the team's velocity in delivering business value, but not how much it will ultimately benefit the team internally. Still, it's perfectly fine to timebox addressing tech debt, whereas it generally is not with user stories.

Ultimately the business is requesting an estimate on when valuable code will be delivered to production. This is kept simple if your user point estimates correspond to business value delivered and technical debt is not pointed. It becomes an exercise in Sabremetrics if you insist on pointing technical debt as you do business value.

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.