Managing technical debts

Bruno Jensen
Ziegert Group Tech
Published in
3 min readAug 13, 2021

Working in a fast pace team aiming to deliver as much impact as possible, sometimes we have to make some tough decisions, which inevitably leads to technical debt. In this article, we will explore some options to manage tech debt before it gets too late.

https://geek-and-poke.com/geekandpoke/2013/11/20/technical-debts

What is technical debt?

Tech Debts are pieces of code that do their job but are overly-complex, hard to maintain and (most of the time) follow some unusual practices. No matter the reason, it could happen to any team.

Working in software development is quite challenging, and requires knowledge about the technology and the business. It’s understandable when some decisions are made to reduce the time to market, but we must be aware of the limits of our software. Otherwise, it could end up unsustainable.

As Martin Fowler mentioned in his article about technical debt:

“The extra effort that it takes to add new features is the interest paid on the debt”.

How to manage technical debt?

Ultimately it’s up to the development team to organise the way they want to handle tech debt. It’s highly unlikely that stakeholders or product owners will reach out to the team, asking them to ‘pay off the debt’. As the name suggests, it’s a technical issue.

With all this in mind, I will list some practices to help manage you tech debt backlog:

The Epic

First of all, consider using an epic that acts as a container to group all of your tech debt issues. If your management system doesn’t allow you to create such a thing, it could be possible with a tag or label. Try to avoid that excel sheet, please. 😊

The Issue

Write it in a way that it’s easy for everyone to understand the problem and its impact, providing all the information you have while it’s fresh. With many things happening, it’s easy to lose a critical piece of information.

The impact here is key. Letting your product owner and stakeholders know that the next big feature will take 50% longer to develop unless the team are allowed to address a particular tech debt issue will act as a great justification for the team to actually start paying it off.

You don’t need to worry about the solution at this point, [spoiler alert] it’s there for discussion during the refinement sessions 😲

Acceptance criteria are a great way to keep in mind how the feature should behave. It’s not a deal-breaker, as they can be aligned later with the team.

The Refinement Session

Having at least one session every sprint where the team can address the hottest tech debts should be enough. The outcome of this ceremony should be some well-defined issues with a direction of how to solve them.

Break down the issues when possible. As per definition, the team should aim to hopefully allocate around 20% of the sprint to work on the tech debt backlog, so picking up small and independent issues could be an option to solve the issue incrementally.

NOTE: Even if the team doesn’t have any more technical issues to discuss, I would suggest keeping the meeting to talk about process improvements and other topics that might be interesting to the team.

Sprint Planning

We’re almost there, but we still need space in the next sprint. Keep in mind:

  • What are the business priorities? How much space will the team have on the sprint? If you already negotiate 20%, it should be fine.
  • If it doesn’t fit, there’s not much you can do. Go back to the refinement session and try to break it down further.
  • Whenever the team have the chance, dedicate a sprint to tech debts. Bring as much tech debt the team can deliver in the sprint. We never know when this opportunity could happen again! 😃
  • Don’t mix it with important business priorities! Timing is key.

Key takeaways

  • Sit together with your team, put a regular meeting on your calendar and build a process to manage your tech debt backlog. Be prepared for when an opportunity to work on them arrives.
  • Negotiate with the product owner how much space you could have on each sprint to work on tech debts, improvements and refactoring.
  • Tests are important, always. Build them based on the acceptance criteria and always build them first. Good luck!

--

--