Technical debt can be defined as “anything that impedes agility as a product matures.” Technical Debt certainly could be code-based, but it could also include:
Technical debt is work that hasn’t met the Definition of Done. Sometimes referred to as “Undone” work, this work automatically returns to the Product Backlog and the remainder of the effort needed to get the item to Done estimated.
“Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”
Wikipedia
The issue is that technical debt isn’t just a hack or workaround. The technical shortcut represents a benefit to the team today to achieve its goal, but will be expensive tomorrow to fix and correct. This approach is unfortunately not an uncommon tactic in teams that are feature factories (Wolpers, 2019).
The Scrum Guide (2020) does not mention technical debt.
According to the Scrum Guide, the Product Owner:
The Product Backlog:
The Scrum Team:
The Scrum Guide is deliberately vague on the question who is responsible for the technical debt to:
Data tells a compelling story, but helping stakeholders visualise data in meaningful ways creates an impact that trumps a report or email. Examine the following in your Retrospectives.
Sprint burndown charts can be a valuable technique for the team to visualise progress towards the Sprint Goal. If you are not using an agile tool such as Jira that creates this chart for you, this can be modeled in Microsoft Excel or Google Charts.
Track the movement of Product Backlog items, not tasks, as they move from in-progress to Done, and display these on the burndown chart. Tracking Backlog items means the team is tracking the delivery of value. At the very least, update the burndown and ensure its accuracy at Daily Scrum.
Track all the technical debt in the same estimation model you are using on your team (break fixes, refactoring, defects). You can label items in your tool, but you may just want to do this manually.
In the last step, use your sprint burn-down as a base, and simply add the time spent on the technical debt on top of the product development work (as shown in figure 4). This will visibly show how much productivity is lost to break-fixes, defects, and outages and other technical debt.
Pay down technical debt regularly every single Sprint. Consider allocating 15 to 20 percent of the team’s capacity each Sprint to handle refactoring and bug fixing.
When the impact of defects and technical debt (waste), is made transparent, we create an opportunity for the Scrum Team to inspect their quality practices. Adaptations that reduce technical debt and prevent defects can ultimately lower the total cost of ownership of the product.
1. Everett, J. (2018) Making technical debt visible. Online at: https://www.scrum.org/resources/blog/making-tech-debt-visible
2. Wolpers, S. (2019) Technical Debt & Scrum: Who Is Responsible? Online at: https://www.scrum.org/resources/blog/technical-debt-scrum-who-responsible
All fields are required.