It’s the most common question I get when discussing agile development as a CIO with a team of developers that are enthusiastic about maturing their practice. How do you get the Product Owner to prioritize fixing technical debt above new features, enhancements, special requests for customers, and improvements to internal tools? How do you get business stakeholders interested in seeing performance improvements, security testing, error logging, automated data processing, code commenting, class refactoring, automated testing, platform upgrading, and in addressing other technical debt?

Can You Handle The Truth?

The simple answer is, without proper culture, incentives or rules most Product Owners will underinvest in fixing technical debt. There are exceptions, but in performing agile transformations now in four organizations I can tell you that the pressure on Product Owners is simply too great and they will almost always drop priorities on technical debt to fulfill stakeholder needs.

The simple way to get technical debt prioritized is for the CIO to step in and establish governance requiring a significant percent of effort applied to this need.

I usually set this at 30%, but it can be as high has 40% for complex architectures, legacy applications with significant risk, or mission critical applications. It can be a lot lower for simple applications.

My rationale is that software companies typically charge 20-30% of license costs to provide support and maintenance. That’s for software organizations selling their software and the typical organization or enterprise isn’t going to be as efficient, hence the 30-40% benchmark.

Prioritizing Technical Debt

Here’s the process I endorse:

1. Technical leads and their teams are responsible for itemizing technical debt stories on the backlog at the end of every sprint.
2. Delivery heads or architects are responsible for prioritizing the technical debt and should articulate their rationale for the prioritization.
3. Here’s where there’s room for a lot of collaboration:

• • The Product Owner can get some of her needs accomplished within the scope of technical debt if she can articulate business needs as part of technical debt stories.
  • The Technical Lead can also get more technical debt addressed if it is bundled in properly selected functionality driven (non-technical deb) stories.
  • Both the Product Owner and Technical Lead have to partner so that these requirements do not drastically change the estimated Size of the story.

4. The Product Owner and Technical Lead abide by the agreed on governance principles to insure the Sprint-level Technical Debt percentage is addressed. The Sprint-level technical debt target should be 5-10% lower than the total technical debt target.
5. The remaining technical debt should be dedicated to 1-2 Technical Debt Releases per year to address larger system or platform upgrades.
6. Smarter teams will prioritize more technical debt at the start of a multi-sprint release and do less of this work near the end of the release cycle when the Product Owner feels more pressure to add more functionality to the  release.

It’s not perfect. It’s not ideal. It does get the job done.