Every codebase carries some amount of technical debt. Every team would like to get better at managing that tech debt.

The first step in managing something is making it visible. A tech debt wall is a simple, effective way to make tech debt visible.

Building a tech debt wall

A tech debt wall is a 2-dimensional map used to track a codebase’s tech debt as individual issues. The Y-axis of this map represents value - how valuable would it be to fix the issue. - The X-axis represents cost - roughly how expensive would it be to fix the issue. Whenever an engineer notices a piece of tech debt, they write a brief description on a sticky (or the virtual equivalent) and place it in the appropriate place on the wall, based on their approximation of the value of fixing the issue and how much it would cost.

When working on co-located teams I’ve built these on a physical wall, using washi tape¹ and some sticky notes and sharpies. Nowadays, they’re just as easy to create in a virtual workspace such as a Miro board.

Tech debt regions

While it’s useful just as a shared place to track tech debt, the real value of a tech debt wall comes from having the various bits of debt placed relatively across the two dimensions of cost and value. With a bit of practice, anyone can walk up to a codebase’s tech debt and understand it in terms of four key regions:

Issues in the lower-left area of the wall are “quick wins” - the sort of ticket you might pick up if you’re looking to clean the campground a bit on a quiet Friday afternoon.

Issues in the upper-left area of the wall are “no-brainers” - low-cost, high-value work that should be tackled soon. Tech debt walls in the wild don’t often have stickies in this region - they don’t stay on the wall long before being resolved, if they even make it to the wall at all.

Conversely, issues in the lower-right area of the board are “nope” items. The juice is simply not worth the squeeze when it comes to these problems. They’ll likely only be tackled if something changes to make them less work to fix, or more valuable to fix.

The remainder of the wall contains “worthy investments” - tech debt items that are likely to provide a good return on investment but are also meaty enough to require negotiation with other stakeholders to get prioritized.

Using a tech debt wall

I’ve seen teams use their tech debt walls in a few different ways. We already saw that they are an excellent place for an engineer to grab a small “quick win” ticket on a slow day, or while they’re waiting to get unblocked on another work item.

A tech debt wall is also a nice place for a product manager and tech lead to have a regular huddle, talking through new issues, and identifying larger pieces of technical work that can slot into the backlog of upcoming work.

Do’s and don’ts of tracking tech debt

Over time I’ve observed some good and bad practices when it comes to tracking tech debt.

• Do encourage everyone to add items of tech debt. Make the process low-friction and low-ceremony.
• Don’t stress about placing each item precisely right in terms of cost and value. Just throw it up there - it can be easily moved.
• Don’t make it complicated. A simple 2-dimensional map is all you need. Avoid the temptation to add labels, colors, or tags, at least initially.
• Do include the axes. I’ve seen teams attempt to track debt using Jira and some custom fields, and it just didn’t work as well. A lot of the value is in the placement of items across those cost/value regions.
• Don’t expect that the team will address every item you place on the wall. As we’ve already seen, some tech debt items just won’t make sense to tackle. It’s still good to add them though, even if it’s just to get it off your chest!
• Do pay attention to the wall. It will deliver no value if it’s just a place where stickies go to die, and engineers will stop investing time in it. Spend time reviewing and grooming the items, and be sure to actually get some of the items knocked off.

When does a tech debt wall make sense

You might be wondering if a tech debt wall makes sense for your team. My short answer is that if you’re thinking about it, then you should try it. I’ve seen most teams benefit from this practice, and regardless it’s a very cheap continuous improvement experiment for a team to make.

Acknowledgements

This tech debt wall concept is something that I picked up from the ThoughtWorks hivemind during my time there. It’s one of the many smart practices which are common across many ThoughtWorks teams, but seem to be quite rare in the broader technical community. This post is my small attempt to right that. If you really want to learn the tricks of the trade, I highly recommend a tour of duty.

I’m not the first ThoughtQuitter to tread this ground. While researching this post I came across this article from Fabio Pereira.

While it sounds very similar, Martin Fowler’s Tech Debt Quadrant is a different idea. A useful model too, just a different one.

Thanks to Will Larson for feedback on a draft version of this post.