Workflow around the Tech Debt epic
When delivering a new feature, planning/scoping it in technical tasks is bad.
When it comes to tech debt…
There is a trendy concept of having a Tech Debt epic in Jira and using it for holding all the tech debt issues.
Sometimes it is just used by the Product Managers to say, “let’s add that to the Tech Debt epic (… and forget about it forever; we must build new features)”.
Sometimes, we use this container to take a few tickets for the next Sprint / Cycle / queue.
Personally, I see the value of having this epic as a container that engineers may use to write down the issues from their heads down into the issue tracker. We shouldn’t be keeping too much information in our heads.
However, I am a complete opponent of working on the issues from this epic.
Define an outcome first
Like when working on a new feature, we must look for a specific outcome we want to achieve when working on tech debt issues. Without a clear outcome, most of our time spent on solving individual tech debt Jira tickets is a waste.
So the exercise goes like this:
Jot down tech debt issues to the Tech Debt epic whenever you find them.
If we want to work on them, we must:
Create a separate epic with a clearly defined outcome.
Move specific tickets from the Tech Debt epic to the new outcome-focused epic.
Plan the execution of the outcome-focused epic.
Examples
Tasks from Tech Debt epic
Let’s imagine an engineer jotted down two tasks:
Write unit tests for Module X.
Change Webpack to Vite to speed up our pipelines.
That gave us visibility into these problems. In the next step, as a team, we asked, “Why do we want to get these tasks done?”, and we came up with 2 desired outcomes.
New outcome-focused epics
Based on the team discussion, we created 2 new epics:
The codebase of Module X is frequently changed (30 PRs a month), and not having the unit tests slows us down. Refactor Module X to make the codebase testable and write unit tests. That will enable us to lower the maintenance cost and build new features without breaking the existing functionality (45% Change Failure Rate in Module X).
Decrease the Lead Time For Changes by reducing the pipeline’s execution time. Currently, it takes 20 minutes to build and test the application. We want to shorten it to 8 minutes. As a result, our overall performance will increase because of lowered waiting-time for each engineer. Our team executes the pipeline 16 times daily. So we can save 192 minutes daily.
Why the outcome-step is that important?
That shows the value behind tech debt reduction.
That generates more (better) ideas for achieving the outcome.
That creates more mature discussions between product and engineering.
That teaches engineers to look for the meaning, not just the code purity.
That doesn’t support an anti-pattern of Never Ending Epics.