Technical debt exists on each project if it’s more than 1–3 months old. Having technical debt doesn’t necessarily mean that software engineers are not performing well. Technical debt can appear because of business pressure, lack of requirements, lack of interaction between team members etc. However, good software engineers know how to manage the technical debt and do that. Bad software engineers simply hide the tech debt from managers and customers, hoping that the project will be completed before it gets out of hand.
Managing technical debt is not difficult process at all, but it requires from at least lead software engineer to be disciplined and follow best practices described down below.
Technical debt register exists for the project
I believe that every software project has a backlog — a list of user stories that will be implemented in the upcoming sprints. The backlog size can range from a few stories to dozens of stories, depending on whether your product owner and business analysts work well or not. In addition to the user stories, backlog should include technical debt tickets.
Please look at the screen:
The first 3 tickets are user stories, the last one is technical debt item. Adding technical debt to the backlog ensures it will not be forgotten by the team.
If Business Analyst is responsible for creating user stories, then Technical Leader is responsible for creating tech debt tickets and keeping them up-to-date.
How to separate user story tickets from tech debt tickets in the backlog?
Each team member or stakeholder should be able to quickly determine if a ticket is a user story or tech debt, how many tech debt tickets exist, etc. There are several ways to do this:
- Create an epic, name it “{my_project_name} Tech Debt” and include all your tech debt tickets in this epic. Check the right side of the screen above. All stories are included in “Core Buyer Functionality” epic, but tech debt OS-0004 is included in “Online Shop Tech Debt” epic.
- Just add the tag “[Tech Debt]” to the title of the ticket, like this “[Tech Debt] Move the payment logic…”. However, this approach doesn’t work well for filtering.
All stakeholders have access to the technical debt register
All stakeholders need to have access to technical debt ticket to see a cleaner picture of the project health. There is nothing to worry about if you put technical debt tickets to the project backlog next to the user stories. Stakeholders will see tech debt as they can see user stories. However, if for any reason you use another register for technical debt like Google Doc, please make sure all stakeholders are aware of this.
Every technical debt item is well-described, estimated and prioritized
Consider technical debt ticket as user story. Each user story has some description (acceptance criteria), estimate and priority. Everything of this is applicable to the technical debt ticket.
Description
I recommend including the following information in the description:
- Reason why it was introduced
- Steps to take to fix technical debt
- Areas of impact for testers
Estimate
Everyone is interested in how many efforts it will take to complete the technical debt ticket. That’s why tech debt should be estimated in story points or hours, depending on your project conventions.
Priority
Technical debt ticket should be prioritized from “Low” to “Highest” by the team of software engineers, so it’s clear how soon tech debt should be taken into the sprint.
Technical debt tasks are included in the sprint during sprint planning
When planning the sprint, pick one or few technical debt items according to their priorities, estimates and team capacity. Ideally working on tech debt shouldn’t take more than 5–15% of the sprint time, because the main goal of the sprint is to deliver new functionality that is valuable for your customer.
Prevent the technical debt register from growing
To keep the project technical debt backlog as small as possible, the team should act proactively and reactively. The goal of proactive actions is to prevent the technical debt from appearing in the project. The goals of reactive actions is to get rid of new technical debt as fast as possible.
Proactive actions:
- Invest more time into analysis of requirements/acceptance criteria of the story before starting development activities. Avoid taking stories with partially defined acceptance criteria.
- Plan development tasks more carefully with the team. The less time was spent on planning the more chances to do rework. But what if there is no time to do that rework quickly? Tech debt…
- During sprint planning try to split user stories into small tasks rather than having one big task for one week of development. A software engineer will be able to create a small pull request for every small task. This approach will allow the reviewer to quickly spot any deviation from the plan, so the author will have to do just small rework.
Reactive actions:
- Just include technical debt tickets into every sprint as we already discussed in the previous best practice.
Conclusion
Don’t be afraid of technical debt. Don’t hide it from customers. Learn how to fight this beast by reading good books and practicing your tech skills. You will definitely win.
Thanks for reading!
Top comments (0)