1. Introduction
Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code.
We have a kanban board to manage our tech debts.https://safibank.atlassian.net/jira/software/projects/STD/boards/43
2. How to create a new tech debt
Everything you think will help our system run better can be created in the “NEW DEBT“ list of the board. like:
problematic requirements
architectural/design/process flaws
duplicated codes
reusable functionalities
code flaws
3. How to identify if the topics in the “NEW DEBT“ list is a tech debt and who to assign
In our weekly tech huddle meeting, we can do:
identify if the topic is a tech debt, move it to the “DELETED” list if it’s not a topic
set the priority of the topic to High, Medium, or Low
assign them to the volunteers, if no volunteers, the person who raises the question can be the owner.
set the deadline of the topic, the principle is that high priority has a shorter deadline
High - 2 weeks
Medium - 1 month
Low - 2 months
4. How to handle the tech debt task
The owner should move the task from “TO DO“ list to the “IN PROGRESS“ list and then work on it.
If the tech debt need more than 1 squad to work together with, the owner need to create multi subtasks and assign it different squad team members and track if they already finished.
If the task was blocked, the owner should move it back to the “TO DO” list and write the reason.
5. How to verify if the tech debt solved?
Tech debt maintainer need to arrange a separate tech debt review meeting with architect and dev leads to verify if the topic should be marked as resolved or not.
If the tech debt owner finished his tech debt, he can move it to the “IN VIEW“ list notify the tech debt maintainer. And the tech debt maintainer will verify it and discuss it in the review meeting. If we all agree to close the topic, we move it to the “DONE“ list.
After that, we need to do a retrospective that why this tech debt happens and how can we avoid it to happen again, and then write the conclusion into the topic. The root cause could be:
incorrect estimation of story points
some one push us to deliver
design/architecture
lack of test cases
lack of review standard
