(This is one of those posts around product management. If you’re not in product management, you have the day off. Cheers! If you’ve heard the term technical debt in your organization before, read on.)

In agile product development, technical debt describes the cumulative corners cut throughout a software project’s design and development. It is everything that makes your project harder to change. In the end, it slows you down.

The debt metaphor is really good. Because debt comes with a cost, namely interest. Interest in the form of (hard to reproduce) bugs and a codebase which is really hard to make adjustments to. Whether the interest is high or low is one of the starting points for deciding on the priority of paying down.

Technical debt can be divided in four categories (as described by Martin Fowler), on two axis: deliberate/inadvertent and reckless/prudent. If there is a lot of technical debt, it might be worthwhile to dive in and figure out in which section of the quadrant the debt accumulates. This post provides a more detailed rundown of the four categories.

Every project has technical debt, but luckily there are some things you can do to help decrease the amount of technical debt:

• Identify and register. This is the first step: technical debt should get a place on the backlog. Items should be scored just like normal items on the sprint backlog.
• Red-green cycle. Each bug that is discovered should be fixed by creating an automated test that fails, fixing the issue and seeing the test succeed. Test gives developers confidence to make changes that improve the quality of the code without breaking existing features.
• Mature definition of done. One of the ways technical debt gets introduced is by shipping a finished feature without meeting the code standards or other requirements. The product manager, together with the team, should decide which of the categories in the Technical Debt Quadrant (mentioned above) are allowed.
• Leave code in a better state. This is the absolute best strategy for dealing with technical debt: anyone working on the codebase should leave the code in a better state than before they started with it. Obviously that doesn’t mean a small story should explode into a full blown refactor, but the team should avoid changes that increase the level of technical debt, whenever possible.

What are your strategies for dealing with technical debt?