Technical Debt Review Process

This page outlines the process of handling and managing tech debt during the OpenLMIS development.

Each new tech debt ticket is created in Jira as a Task with the label TechDebt (it already exists and there’s a quick filter).
- No Stories or improvements. Epics are okay.
Transition the Task from Roadmap status straight to To Do.
- We’re going to experiment with skipping Roadmap just for TechDebt.
- This is not what we have in our Ticket Workflow, but we need to do this to use Jira grooming later.
Developers are allowed to suggest tickets for consideration during next sprints on the #tech-debt Slack channel
- One ticket per one message is allowed
- Developers can vote on the ticket using :+1: emoji and estimate the ticket with the number emojis
- Once the ticket reaches at least 4 votes, it is added to the TechDebt Next sprint
- The TechDebt Guard is constantly watching the #tech-debt Slack channel and the TechDebt Next sprint and advises the developers if action is needed (more votes, suggestions, estimates, etc.)
- The TechDebt Guard adds tickets to TechDebt Next after it reaches the threshold and sets estimates
- In case of huge discrepancies in estimates or questions, Slack's threads are used to discuss and come to a conclusion
As we start a new sprint, we’ll pull tickets from the TechDebt Next.
- We’ll never start the Tech Debt Next dummy sprint, it’s just for organizing and grooming.
We know we’ve estimated enough when the TechDebt Next sprint is roughly 20% of our total estimated velocity.
During the sprint we can see which Jira issues are TechDebt with the Quick Filter Tech Debt.

Who is the TechDebt Guard?

A person appointed by the team lead to watch over the Tech Debt process and fulfill the above tasks. The appointed TechDebt Guard at this point is Klaudia Pałkowska (Deactivated).

Why a label?

We’re going to use a label as TechDebt can take a number of different forms, and we want a consistent way to find it.

How about Bugs?

Tech Debt could be a Bug, however I think more often than not a Bug should be kept as something that prevents an end-user from accomplishing a stated functionality of OpenLMIS. More importantly Bugs will be groomed and prioritized separately as they always have been. To control when we address some tech debt, keep it as a Task and label it TechDebt. If it’s a bug and it doesn’t have immediate value to the end user, it likely will be awhile until Bug Grooming prioritizes it.

The tech debt wiki page?

Lets start transitioning the items into Tasks in Jira with the label TechDebt. Once an item in that page is in Jira, lets remove it from that page and if we like this process we’ll remove the page once it’s empty.

Uhm, what is this Platform component?

This component tends to become a dumping ground of everything that doesn’t fit somewhere else. Lets not add tech debt to it. In fact I’ve re-named this component to Architecture to better distinguish where we find our Architectural backlog. My goal is to add issues to, clean-up and prioritize it to fit its name so that there’s an up-to-date issue list to see our Architecture priorities and wishes. I’ll continue to flesh items out in this component and get them groomed through the feature grooming process.

Skip Roadmap!? What about acceptance criteria?

Yes we’re skipping the Roadmap status and going straight to To Do. If we didn’t then we couldn’t use the same agile jira board to groom the tech debt backlog as the one that holds our sprint - adding overhead. I also think that generally we the developers know what the rough acceptance criteria for tech debt should be, enough so that we don’t need a fully formed ticket and a separate status to move through to ensure everyone’s on the same page - for prioritization at least. We will need that well formed Acceptance Criteria to estimate however, so don’t use it as an excuse to leave the juicy details out.