Software Engineer, Tech Leader
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.
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:
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.
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:
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.
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.
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.
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.
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!
Create your free account to unlock your custom reading experience.