Technical Debt Management Best Practices for Software Engineers

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 technical debt. 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 a not difficult process at all, but it requires the lead Software Engineer to be disciplined and follow the 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 a Business Analyst is responsible for creating user stories, then a Technical Leader is responsible for creating tech debt tickets and keeping them up-to-date. How do you separate user story tickets from tech debt tickets in the backlog? Each team member or stakeholder should be able to quickly to 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 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. “{my_project_name} Tech Debt” Just add the tag “[Tech Debt]” to the title of the ticket, like this However, this approach doesn’t work well for filtering. “[Tech Debt] Move the payment logic…”. All Stakeholders Need Access to the Technical Debt Register All stakeholders need to have access to technical debt ticket to see a clearer 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 a user story. Each user story has some description (acceptance criteria), estimate and priority. Everything of this is applicable to the technical debt ticket. I recommend including the following information in the description: Description Reasons why it was introduced Steps to take to fix technical debt Areas of impact for testers 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. Estimate Technical debt ticket should be prioritized from “Lowest” to “Highest” by the team of software engineers, so it’s clear how soon tech debt should be taken into the sprint. Priority Technical Debt Tasks are Included in The Sprint During Sprint Planning When planning the sprint, pick one or a few of the 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 technical debt from appearing in the project. The goals of reactive actions are to get rid of new technical debt as fast as possible. Proactive actions: Invest more time into the analysis of the 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: Include technical debt tickets into every sprint, as we already discussed previously as a 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! Also published at https://programmingstuff.medium.com/technical-debt-management-best-practices-for-software-engineers-871a315ac812