Making Tech Debt Visible
Advanced
difficulty
Stage 2
Agile IQ® Level
Backlog Management
Practices
Scrum
Framework
Introduction
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:
- A lack of automation – whether it’s workflow support for finance, HR, marketing, or automated testing for software teams.
- Lack of technical DevOps support, including CI and CD.
- Rework that is needed in architecture.
- Build problems that have yet to be addressed.
- Growing rework.
- Growing defects and bugs.
- Elements that need re-design.
- Documentation that hasn’t been kept up-to-date.
- Infrastructure that is lagging behind and not yet updated.
- Skills defecits in people that need attention.
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.”
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).
Who is responsible for technical debt?
The Scrum Guide (2020) does not mention technical debt.
According to the Scrum Guide, the Product Owner:
- Is responsible for maximising of the value of the work of the team.
- Manages the Product Backlog, its content, and orders Product Backlog items.
- Discusses Product Backlog items suitable to achieve the Product Goal for the coming Sprint during Sprint Planning.
The Product Backlog:
- Represents the only work that the team will work on and comprises everything the product requires to be valuable.
The Scrum Team:
- Never compromises on quality, represented by the Definition of Done.
- The Definition of Done is provided by the organisation, based on its standards, practices and even areas of compliance. If one doesn’t exist, the Scrum Team need to develop one.
- The Scrum Team picks the Product Backlog items it deems necessary to achieve the Sprint Goal at Sprint Planning.
- If necessary, the team adds new Product Backlog items to the Sprint Backlog as more is learned.
- If the team improves the definition of “Done,” rework of former product Increments may become necessary.
The Scrum Guide is deliberately vague on the question who is responsible for the technical debt to:
- Foster collaboration amongst all of the team members, including the Product Owner.
- Encourage self-management.
Actions To Try
Retrospective actions
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.
Step 1: Start with a standard sprint burndown with an ideal line
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.
Step 2: Be diligent about tracking daily progress
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.
Step 3: Track technical debt
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.
Step 4: Use your sprint burn-down
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 back technical debt regularly
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.
References
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.
