How do scrum teams manage technical debt?

Technical debt is a metaphor that leans on the idea of financial debt. As financial debt increases, the ability to repay the debt is reduced. Once the debt exceeds the ability to repay, bankruptcy occurs. So, how do scrum teams manage technical debt?

Over time decisions are made either by the product owner or by the development team to build a part of (or whole) the system in a less than optimal way, or the team may have sacrificed quality by design or by ignorance. These decisions remain in the system and the effects accumulate over time.

As technical debt accumulates, the ability to maintain and change the system is reduced and the cost of adding new features increased. This culminates when the system can no longer be maintained at reasonable cost or speed, to meet the business needs and expensive re-platforming or re-writes are required.

Examples of technical debt

What to do about existing debt

Unless you’re yet to break ground on a new product idea the chances are you already have a certain amount of technical debt. Some debt will be well understood already and can easily be identified. Other debt will take a little analysis. There are a number of tools available that can help specifically with this.

The important thing to do is to add items to the product backlog to enable technical debt to be prioritised by the product owner and to be addressed in future sprints.

Technical debt does not need to be written as a user story but should have sufficient information to enable someone to return to the product backlog item (PBI) in the future and still understand what the issue is and the value of fixing it.

How to stop creating debt

The key mechanism in Scrum to drive higher quality standards is the definition of done. The definition of done should be reviewed frequently during sprint retrospectives and added to. Typically, as teams look to eliminate technical debt, they’ll add some of the following to their definition of done:

  • Automated acceptance test
  • Automated unit tests
  • Refactored code
  • Use of patterns
  • Clean code
  • Clean architecture
  • Successful build
  • Integrated

Ready to get started?

Our team of business agility experts are here to help

Contact us

Discover new insights

I’m a product owner not a feature... By Paul Grew

Read More
Agility.im

Sign up for our newsletter

Keep up to date with all the latest business agility news

Sign up to our newsletter