Scrum | Technical Debt | Planning

So, what is Technical Debt really?

According to Wikipedia,

“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.”

Why Tech Debt is incurred?

There are two categories of technical debt: intentional and unintentional.

What is NOT Tech Debt?

A common misunderstanding about technical debt is that it refers to many other software project issues, which is an incorrect interpretation for technical debt to be. Technical debt does not refer to individuals in the team, incorrect processes used during development, or poor engineering quality that comes from lack of experience.

Why Important to be solved Tech Debt on time?

When low-quality code is written with the promise of improving it later, technical debt is incurred with the promise of paying it back later. But the nasty thing about debts is that you have to pay interest. And the greater the debt, the greater the interest. Until you find yourself spending all your time dealing with the interest.

Sometimes we’re fine with some technical debt, and the resulting interest, but more frequently we’re not.

I’ve seen so many companies drowning in technical debt, moving painfully slow, losing key developers that they didn’t take code quality seriously from the beginning because it’s so much more expensive to fix it afterwards.

Tech Debt Planning within Sprint / Ownership

Handling technical debt, requires a trade-off. The long-term goal of achieving business agility cannot be reached as a feature factory churning out new features. At the same time, an application in a perfect technical condition without customers is of no value either.

Consequently, dealing with technical debt in Scrum is a responsibility for the Scrum Team as a whole and as such an excellent example of Scrum’s built-in checks & balances.

Dealing with technical debt should be a concern of the whole Scrum Team. There are a few proven techniques that will make this task more manageable:

• Be transparent about technical debt. Visualize existing technical debt prominently so that everyone is constantly reminded of the nature of your code-base. Don’t hide it from the Product Owner. Treat them as a regular item for the Product Backlog; break down large items as needed and prioritize them with the Product Owner.
• Use code metrics to track technical debt, for example, cyclomatic complexity, code coverage, SQALE-rating, rule violations. (There are numerous tools available for that purpose.) At least, count the number of bugs.
• Pay down technical debt regularly every single sprint. Consider allocating some % of buffer of the Development Team’s capacity each Sprint to handle refactoring and bug fixing.
• Tech Debt should be added to Product backlog. There is no shadow accounting in Scrum.
• Create a standard procedure on how to handle experiments that temporarily will introduce technical debt to speed up the learning in a critical field.