Ward Cunningham, a software developer who, in addition to being one of the 17 authors of the Agile Manifesto, is also credited with inventing the wiki, coined the term “technical debt.” He first used the metaphor to explain why refactoring resources needed to be budgeted to non-technical WyCash stakeholders. He had coined a new buzzword in the software community, which he didn’t realise at the time. It would go on to be the subject of a slew of academic studies, debates, and panel discussions later on.
Cunningham explained how he came up with the technical debt metaphor years later:
“With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.”
Technical debt, like monetary debt, can accrue “interest.” The focus of this concept is on the increasing difficulty of implementing changes later on, particularly as a software project progresses through multiple phases. The longer technical debt is ignored or unaddressed, the greater the likelihood of software entropy.
When the Scrum Team learns more about the problem it is trying to solve, there is also a kind of technical debt that is created invisibly. In comparison to the solution implemented just six months ago, the Development Team may prefer a different solution today. Alternatively, the Development Team may change the definition of “Done,” requiring rework in previous product increments.
According to the Scrum Guide:
- The Product Owner is in charge of maximising the value of the Development Team’s work.
- Product Owners accomplish this by managing the Product Backlog, which can be seen in the content and order of Product Backlog items.
- The Product Backlog is the only set of requirements that the Development Team will work on, and it should include everything that the product needs to be useful.
- Quality is never compromised by the Scrum Team.
- The engineering organisation or the Development Team determines what constitutes “done.”
- The Product Owner discusses Product Backlog items that are appropriate for achieving the Sprint Goal during Sprint Planning.
- Only the Development Team, on the other hand, selects the Product Backlog items that are required to meet the Sprint Goal.
- As new information becomes available, the Development Team adds new Product Backlog items to the Sprint Backlog as needed.
- Rework of previous product Increments may be required if the Development Team improves the definition of “Done.”
As a result, the Scrum Guide is purposefully ambiguous on who is responsible for technical debt in order to foster collaboration and self-organization, beginning with the Scrum values—courage and openness come to mind—and leading straight to transparency and Scrum’s inherent system of checks and balances.
There are a few tried-and-true methods for making this task more manageable:
- Be open and honest about your technical debt. Make existing technical debt visible so that everyone is constantly reminded of the state of your code. Also, address technical debt at Sprint Review events on a regular basis so that stakeholders are aware of the application’s status.
- Code metrics such as cyclomatic complexity, code coverage, SQALE-rating, and rule violations can be used to track technical debt. (There are a variety of tools available for this.) At the very least, keep track of how many bugs there are.
- Every sprint, pay down technical debt on a regular basis. Consider allocating 15 to 20% of the Development Team’s capacity to refactoring and bug fixing each Sprint. (For more information, see 19 Sprint Planning Anti-Patterns.)
- Ensure that all tasks related to dealing with technical debt are included in the Product Backlog—Scrum does not allow for shadow accounting.
- Adapt your definition of “Done” to reflect your understanding of product quality, such as by defining code quality requirements that help keep technical debt under control in the long run.
- Create a standard procedure for dealing with experiments that introduce temporary technical debt in order to accelerate learning in a critical field.
Conclusion
Despite the fact that many companies are using Scrum to add high value to their projects, the formation of technical debt is still a possibility. The key to managing debt is clearly defining and keeping the debt status transparent, regardless of how efficient the teams are. In each splint of the project, the entire team should work together to understand, measure, and pay off technical debt. The debt report should be an important part of the Splint reviews, and it should be addressed as soon as possible.
Technical debt is inherently present when considering addressing a dilemma in a particular paradigm. It constantly leads to new qualifications and competence to uniform existing verdicts. As a result, dealing with technical debt necessitates a concession. A showcase manufacturer with additional features will not be able to achieve the long-term goal of organizational versatility. For example, a customer’s additional components appear to be inflexible. As a result, in Scrum, the management of technical debt is the responsibility of the Team member, demonstrating Scrum’s integrated safeguards.
