What is technical debt?
It’s like gum stuck to your shoe – you stand steady in one place but you can hardly move on.
Short-term solutions that guarantee long-term pain.
It may relate to every component of the platform – application code and infrastructure.
We use the financial debt metaphor because sooner or later we will have to pay it off – do the same thing better. The longer you wait the greater the cost.
The scrum team deals with technical debt by registering it in the product backlog, describing its severity, and systematically reducing the debt. The work on debt reduction should be planned according to its priority and the product roadmap.
Why do we have technical debt?
In all good will we want to develop the best working piece of software.
1. Sometimes we NEED to make a solution with a debt.
Example:
In the first stage of software development, we want to make a proof of concept (POC) to verify a value hypothesis. At this point, we want to show this version to the customer or to the end users and find out if that is what they really need. It makes no sense to do this version by the book and pay for detailed and robust development – we want a simple, easy-to-show solution. We want to prove our concept right.
If that concept is accepted we can start all over and follow all principles and good practices. If we work on the version shown to the customers so they can make up their minds – we know what to improve. That is a debt taken consciously – we don’t waste time, energy, and money to work on something that can be obsolete in no time.
There are of course other situations where we know that the code or other piece of the system, or a process will need improvement.
Most of the time it is the pressure of time to meet a deadline or lack of knowledge.
This conscious debt-taking is a good decision at that point in time but in the future will not be optimal because of advancements in technology or changes in business demand.
2. Sometimes we just make a solution with a debt.
Nobody wants to be imperfect but we all are. The debt taken unconsciously may come up for example on the code review. Still, there can be no time left to make it right, and somehow – the application does what it is meant to.
If no one spots the debt can we somehow figure out if it exists and where?
There are tools that can help us find out about it:
- Static code analysis – for example, SonarQube
- Error monitoring software – for example, Sentry
- Reports from penetration and security tests
As a developer, you surely know those and other ways to filter out the shortcomings in your code.
As a scrum master or product owner you should know that those tools exist – plan their implementation with your development team. They can save you a ton of time and nerve.
What are the sources of technical debt?
Below is a list of a few examples, the list is never complete…
- Code was written at the startup stage – when quality wasn’t the most important thing
- Code was written in the past – when we knew less or the technology was different
- Shortcuts – there is time pressure and we need to deliver a working solution fast (apply to the above examples)
- Code was written in an old version of the programming language or framework
- Code doesn’t meet NFRs – at the time of programming there were no quality requirements or they were lighter
- Functionalities or integrations are deleted – there is a mess that needs to be taken care of
- Poor software architecture
How scrum team deal with technical debt
Know your debt
If you take it consciously – register it in the product backlog right away.
Look for debt taken unconsciously – register it when you find it. If the developers are experienced they will notice the debt most of the time but a couple of sessions with an architect or other senior developer never hurt anyone. Especially the inexperienced team would benefit from the help of senior colleagues. There are also tools to help uncover debt that is lurking somewhere in your code. Use those tools, and make penetration or security tests that point to other issues with your system – after all, we want it to be the best right?
For transparency purposes, the product backlog should include improvement-type items along with new features, enablers, and other types. The scrum team works with the product backlog – I don’t see any point in having a separate registry for technical debt.
Link the newly created issue that represents the debt with a done issue that could use improvement. Along with the description, the link will provide a context for a better understanding during future discussions about debt reduction.
Of course, if there are really minor issues with the code it would be an abuse to go to Jira and create an issue. Form over substance. You can make some comments in the code and come back to it later. We must maintain common sense. The scrum team should agree on the magnitude of corner cuts that deserve a place in the product backlog.
Describe your debt
Answer a couple of questions:
- What is the debt?
- Why is it a debt, why we took it?
- How it should be done, and what is the labor intensity?
- What is the impact on the application? List features or stories.
- What is the impact on the ease of future development?
- Were there any other options considered?
How to manage technical debt
You can manage your technical debt only if you know that it exists and how it influences your application and further development in the context of future business demands.
So if the backlog and description part is done right – you can work as a scrum team on priorities.
Who prioritizes technical debt?
Prioritizing technical debt should be teamwork. Collaboration between a technical leader or the whole team and a product owner.
Based on the estimated impact a debt can have on the application and future development choose the priority in which debt should be reduced. The product owner will have to decide on sprint planning between new features and quality.
From my experience – product owners often prioritize new features. They see it as a measure of their effectiveness in working with the product because the users tend to appreciate new features more than the technical issues behind them. Make clear that the possibility of working on new features is low when the technical debt is high. Also, performance, security, and other NFRs are sources of application success. The discussion on the priority of quality improvements is vital to a shared understanding of what the product needs most at every stage of development.
Track the debt and its payment
If you can track how much debt you have in your product then you can manage it. Also, track the payment of the debt. If you have a different issue type for your debt or some other kind of label you can easily filter all your debt out. It will certainly do good for team morale to see that the quality is improved systematically, they can be proud of the code they write and they are under the control of its sensitive parts.
When should a team address technical debt?
Plan to pay the debt off systematically
Execute the debt reduction. Sounds simple but is it?
Should we focus the whole sprint only on refactoring? In my opinion that is not a good option. If the situation is getting out of control then you don’t have o choice – you need to put the fire down. If the situation is stable then every sprint should have an increment. You should put debt reduction items along with stories you consider to be important. So if you have the priorities of the debt well figured out you will find the balance. In every sprint planning take the technical debt part of the backlog into consideration.
When working in SAFE every Program Increment has the last sprint as an innovation and planning iteration. You can allocate some of the debt reduction work in that last sprint.
Don’t underestimate your debt
Never put it off indefinitely.
It depends on the severity but the debt backlog can grow rapidly. Especially if you develop parts of the code that are already in debt.
Take it seriously and plan to reduce it systematically.
How does technical debt fit into a product roadmap?
Technical debt can fit only to the internal roadmap, it should be on a high level of generality and be related to another business item.
Internal roadmap – may include some high-level debt reduction milestones. The debt is obviously consciously taken and its reduction is related to specific features appearing in the roadmap.
Example: the roadmap assumes scaling up the application to a broader market at a certain point. For economic reasons, it wasn’t working on services that enable effective scaling. The original architecture didn’t include easy transferability to professional cloud services. In this situation, we have a technical debt that is related to a business feature. It is a high-level internal item that could be called “Enable scaling” – everything that needs to be done at the team level should be refined in detail on product backlog refinement meetings.
Roadmap for clients – this kind is used for marketing purposes. Technical debt shouldn’t be mentioned in it at all – it can have a deterrent effect on your clients.
From my experience – technical debt doesn’t appear on roadmaps that are most of the time dominated by features. I personally think certain milestones that represent technical debt could find a place on a roadmap, especially if there is much work to be done to reduce them.
Is it a risk to have technical debt?
It is risky to have debt and no control over it. If the team never does anything to minimize technical debt and it grows – the risk is growing from sprint to sprint.
What are the consequences of that risk?
- it is harder to develop new features
- it takes longer to create new features
- high probability of application downtime
- poor performance
… and more.
If we consider a single corner cut – it simply depends on the debt. The risk and the priority of paying a particular debt off is an individual matter.
How does technical debt influences the product owner’s decisions?
The product owner must decide what kind of work a developer should do in every sprint. If the product owner is aware of the debt – and that should be always true – he or she should consider paying it off when planning a sprint.
The priority of every debt should be estimated during backlog refinement or during a dedicated meeting.
Depending on the priority of the existing debt the product owner must decide whether a sprint increment will be full of functionality or will it consist of more quality and risk mitigation.
When the debt isn’t paid – the interest grows. This metaphor shows that the more debt we have the fewer new features we can develop. At some point the debt service is so expensive – we can hardly maintain the application. An example of this can be debt in application performance – when the number of users grows rapidly and the software isn’t ready for such scaling.
How does technical debt influences a scrum master’s work?
Technical debt is another thing to track for your development team.
The debt issue itself is something a scrum master should address with the scrum team.
Establish an agreement between the developers and product owner on how the debt will be registered and managed.
When the debt is small then there isn’t actually much to bother with. The question is – does the team look for a possible debt? Maybe it is bigger than they think it is. Maybe a tool, consultation, or test would be a great idea to propose if the debt subject isn’t really in the team’s interest. It is a scrum master’s role to help the team make good decisions. If the debt subject doesn’t come up – bring it into the retrospective and facilitate a discussion around this topic.
Growing technical debt can be also considered an impediment to the team’s way of achieving high quality. As a scrum master, you should be familiar with this subject. You should know the risks and be able to talk about them with the scrum team and propose solutions to manage the debt. Exactly as mentioned above, or maybe you have some better ones 😉
Note that the more debt we have the more uncertainty in estimating the tasks during planning. Therefore development can be slower or be more exposed to bugs.
If the team is unaware or forgot about debt the estimations will be inaccurate – which results in poor predictability.
The chart above is a simplification – it does not include all the different factors that influence the team’s velocity fluctuations. It is only an illustration of how systematic debt reduction allows the continuous development of new features.
With knowledge about technical debt, the scrum master can be of use to the product owner. Good debt detection and management are in the product owner’s best interest. This is an addition to the post about How Scrum Master helps Product Owner
What is technical debt in Jira?
Technical debt in Jira is an issue that is telling us which delivered functionalities need improvement. They should have been done in a different way to meet business demands, organization standards, NFRs, or good practices.
Technical debt is a part of the product backlog. It should be taken into consideration when planning the sprint backlog. When technical debt is planned to be worked on during a sprint it obviously becomes a part of a sprint backlog.
Of course, if you work in kanban, you won’t have a sprint backlog – you will have prioritized issues to take accordingly with your workflow.
Linking technical debt issues to functionalities that need improvement is an exemplary practice. Knowing in the future where the debt came from is one thing, being able to find the source issues is another. It provides context and gives hints about the impact and therefore – priority. I suggest using the ‘relates to’ type of connection but it doesn’t really matter – choose a specific type and stick to it.
You can also link technical debt issues to a bug that emerges in the application. If the bug is the consequence of existing debt it is a good practice to link the bug with the ‘is caused by’ type of relation to point it out. Using this debt-bug connection can allow gathering some statistics – scrum master can sum up and show how often unpaid debt lead to bugs in the software. Not to indicate the failure – to start a discussion about what the team should focus on to make a high-quality product.
For the technical debt workflow, you can use a basic ‘to do, in progress, done’. Plus incorporate the statuses you use in your team for the type of work that debt relates to. For example, if the debt is about coding corner cuts – use status like ‘code review’, ‘testing’, or whatever you use on your board.
Is technical debt a user story?
No, technical debt is not a user story.
A user story describes what the user wants or needs to do in a broader context.
Technical debt doesn’t describe a user’s needs regarding software, nor anything about the user and the context that the user is in.
It is an indication of what technical part of the system needs improvement and how risky it is to keep it the way it is.
It can be related to a user story – if it is one of the core features then it can be one of the factors to consider this debt as a higher priority.
In conclusion
This text is process design based.
It doesn’t give you any technical details about how to solve specific problems in coding, infrastructure, or whatever your debt is.
It is about how to organize your scrum team around the inevitable topic of technical debt and how to manage it.
Bringing the debt into the environment that the team is working with on a daily basis – the product backlog is from my experience a good way to deal with it.
