Scrum Guide
FAQ
← Back to FAQ

What Is Scrum Technical Debt?

Technical debt is a concept in software development that refers to the potential cost of rework caused by taking an easy solution over a longer but better approach. 

To give a simple example: Imagine you are building a chair. You choose the materials you can get quickly and cheaply. The resulting chair is fine — until one day, weeks later, it breaks beneath you. Now you have to re-make your chair, adding work you could have avoided if you’d spent more time on it in the first place.

Examples of Scrum technical debt can include code copied from another project, untested code, or ‘spaghetti architecture’ (code that is unstructured and difficult to maintain). The shortcut is beneficial today but could become expensive tomorrow when you have to go back and fine-tune your work.

How do Scrum teams deal with technical debt?

Though the official Scrum Guide does not mention technical debt, it is an inevitable part of software development. 

In Scrum, the product owner is responsible for managing the product backlog, which lists all the work that needs to be done to complete the project. The development team picks the product backlog items it will work on in the upcoming sprint.

The definition of ‘done’ (DoD) in Scrum is a collection of criteria that must be present for a backlog item to be considered complete. It’s a checklist that helps the team come to a shared understanding of the project deliverables.

The DoD drives Scrum teams to reach higher quality standards. However, they may discover new information in the course of their work that can change the definition of ‘done.’ This, in turn, can lead to rework on previous product increments. So, how should teams handle

Scrum technical debt and avoid getting overwhelmed by it? 

  • Be transparent about Scrum technical debt. One of the main principles of Scrum is empirical process control, which is based on the ideas of transparency, inspection, and adaptation. Don’t hide technical debt from the product owner or stakeholders. Address it at sprint review ceremonies and visualize it for the team.
  • Add technical debt to the product backlog. This allows the product owner to prioritize the technical debt in future sprints and allocate team resources to rework and bug fixing.
  • Adjust your definition of ‘done.’ A good DoD should include the tasks required to ensure that technical debt is addressed — for example, you could stipulate that “code should remain stable when new features are added” for an item to be ‘done.’

Scrum technical debt is the responsibility of the entire team, but with the core Scrum principle of transparency in mind, dealing with it becomes much easier.

Further reading
blog post

What Are the 5 Scrum Values?

article

How to Run a Scrum Meeting

other

Guide to Scrum Sprints

other

Scrum Product Owner