Right now, my team analyzes the bugs we've fixed within the last month and discuss about them, like what to do to prevent them in the future. We also discuss certain metrics on our products' debts, like test coverage, code complexity, risks, etc.
I'm gathering ideas on how everyone else is doing tech debt analysis and wondering if we could steal some ideas for my own team so that we could make these sessions more effective.
Here are a couple of questions I'd like to inquire:
- What's the general process for identifying/analysing tech debts in your team?
- What tools do you use to facilitate the discussion?
Top comments (1)
Hi,
I think for me, the problem is often relating to prioritising the fixes. As engineers, how do we go about communicating to our stakeholders and product owners the value of resolving tech debt?
I found a really valuable post by Riot Games (The company behind League of Legends), titled "The taxonomy of tech debt". It details how you may measure the impact, fix cost, and how likely tech debt is to spread, it's a great read and is available here: technology.riotgames.com/news/taxo...
I've created spreadsheets before to help discuss our tech debt related stories (These are stories raised by anyone in the team ahead of these discussions). This helps get them prioritised against new features and other work.