Making Tech Debt Visible

As a Product Owner, there is nothing more frustrating than using valuable development time to deal with technical debt. We use the debt analogy to remind us of the imperative need to mitigate it, to keep our products scalable and sustainable. But it still seems difficult to communicate the value of refactoring to stakeholders primarily focused on customer-facing features. So, we often don’t talk about it. It’s like the first rule of Fight Club. Our business partners don’t want to acknowledge it, we get tired of delivering dire warnings, and the debt continues to accumulate. There comes a tipping point where it will start to affect the user experience negatively, and by then, you are in a real fight to stay ahead of losing customers.

If this sounds familiar, read on to explore how to persuade stakeholders that improving the product behind the scenes will allow your team to spend more time doing the work we all care about — giving our users features they love. And in the meantime, improve productivity, sustainability, and scalability.

Technical debt is defined, for this post, as “anything that impedes agility as a product matures.” Technical debt can be code-based, but it can also mean a lack of test automation and increasing DevOps issues.

Note: For the purposes of this post about making tech debt visible, we will not get into the strategies of solving it. For more in-depth references, visit Frances Lash’s article on managing technical debt or the valuable series on this topic on Scrum.org.

No matter how you define it, we can all agree that technical debt is a measurable risk and must be mitigated.

If your goal is to connect with stakeholders effectively and show the impact that technical debt is causing, data tells a compelling story. And visualizing that data in meaningful ways creates an effect that can enable the development team and the business people to have a courageous conversation about spending time on reducing technical debt.

Here’s a 4-step process to visualize technical debt created with simple math and a drawing.

1. Create a burndown with an ideal burn rate line. Start on the y-axis by showing the total number of units (or hours) estimated for the planned work. On the x-axis, apply the number of working days in your timebox or Sprint. Divide the number of units by the number of days in your timebox or Sprint to visualize an ideal burn rate. Here’s an easy example: If you have 500 hours of work to be done and ten days to do it, your ideal burn rate would be 50 hours a day.

2. Be diligent about tracking your product work’s daily progress to show the actual completion rate and the total work remaining. Do not include any effort that your team considers technical debt. (Technical debt could include break fixes, refactoring, defects, and perhaps any time accrued to manually move work from a Done status to a Released status.) Software is complex, and it shows up in our daily progress. Teams typically have a jagged line that reflects the true burn rate. Some days, the remaining work estimate will increase, and on others, the team completes the work faster than expected.

3. Track all the technical debt in the same estimation model you are using on your team, whether in units, hours, or points.

4. Add a new line showing time spent on the technical debt by adding it to the actual burn rate line to show the difference and illustrate productivity lost to technical debt.

When the impact of defects and waste is made transparent, we create an opportunity for the delivery team to inspect their quality practices, and we can show stakeholders the impact. To lower the total cost of ownership of the product, the team needs to make adaptations that reduce technical debt and prevent defects. That is music to a Product Owner’s ears.

For more tips on making technical debt visible, review Ian Mitchell’s post on Scrum.org about using a technical register and comparing it to the RAID technique.

If you are using the Scrum Framework, the Sprint Review is the event best suited to connect your Stakeholders with the impact of technical debt. The Review is a scheduled, recurring feedback loop in Scrum intended to engage stakeholders strategically. If you aren’t using Scrum, consider a similar event specially designed to trigger this conversation.

If you want to connect with business partners, use their language: speak business. For example, avoid using ambiguous terms such as points and a lot of tech speak. Translate the impact of refactoring, context switching, and lost work from time into dollars. It’s more meaningful to talk about cost and budget and more compelling to show stakeholders the benefits they promote themselves.

It starts with some simple math. (I know, more math.) If you know your blended rate, it’s an easy calculation. If you don’t, I suggest picking a number based on what you can gather and start there.

Here’s a sample business case:

1. You believe your team has a fully-loaded, blended rate of $80 an hour. (Trust me, if you are wrong about this number, someone will be happy to correct you.)
2. Using the $80 rate, assuming an 8-person team, and a 2-week Sprint, your Sprint cost is $51,200. ((8*80)*80)
3. Your team reports they spend an average of 32 hours each Sprint dealing with issues that can be traced back to unpaid technical debt. That’s $2,560 of waste. You can do the math — and it adds up quick: $2,560 over 52 weeks is $133,160.
4. Your team also forecasts that they need to refactor critical code used in multiple components, and it will take two Sprints.
5. Doing that quick math will show you that it may cost around $100,000.
6. Asking for $100,000 is probably not your best opening line. Pause to consider your audience, what they typically speak up about, and argue for. Frame your conversation to get their attention.

Is your company struggling to make the numbers meet? Your pitch might start with: “Let me show you how we can forecast a 5% increase in productivity with a small technical initiative. In our team, that 5% means over 800 hours of development time a year!”

Need to earn some goodwill in a time of downsizing? Your pitch might start with: “Let’s talk about how to add the equivalent of a full-time developer to the team, without adding headcount.”

You may have to do some a tad more complicated math to forecast the lifetime benefit of the improvement you are proposing. And in all reality, at best, it’s probably going to be an educated guess. Pull out your most compelling user observations, your declining feature use, your passive net promoter scores, and your user behavior metrics to augment your numbers. Be authentic, be prepared to show your work, and be ready to tell a story.

Real user feedback that evokes emotions can be another way to illustrate the impact of technical debt on your business audience.

In conclusion, data, images, and storytelling are robust in the war against technical debt. In the end, perhaps there’s nothing technical about it.

Let us know if these tips help your team become more proactive about reducing tech debt and having those courageous conversations. What else have you used?

~Julee Everett

Hone your craft, speak your truth, show your thanks

---

Want to learn more about how to improve your engineering practices through an assessment or the application of DevOps? Connect with us at ClearlyAgile.com to find out how we help our clients with DevOps training and implementation. Great news! We are now a national DevOps partner of Vaco.