OpenLMIS Tech, lets take a moment to discuss our favorite topic: Tech Debt and how we address it.
To recap a few approaches we’ve tried:
- We have a Technical Debt wiki page (which we don’t groom often enough - mea culpa)
- We’ve turned them into Bugs (getting lost in the actual list of bugs)
- We have/had a Component named Platform (which has everything from Tech Debt to future looking architecture)
- We have/had a couple labels: TechDebt and TechBacklog (which I’ve transitioned so that we only now have TechDebt)
I think it’s fair to say that tech debt doesn’t always get prioritized, or the prioritization occurs too far removed from the developers whom have to live with the debt. To fix this I’d propose that we, the technical committee, start creating a cohesive tech debt backlog which we will groom for each sprint iteration knowing that we’ll always have a bucket of time set-aside to fix the technical issues that most need addressing.
To achieve this I propose we start with the following:
- Enter new TechDebt 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.
- Once a sprint we, the developers and tech leads, will groom the TechDebt backlog by first prioritizing in the issue list, and then by ranking them on the board.
- I’ll send out a meeting invite for sprint 51 to kick it off. Then perhaps we can move it to a slack channel.
- Grooming the backlog is our responsibility and it won’t occur in the regular grooming sessions (which I think we should refer to as feature and bug grooming).
- As we start a new sprint, we’ll estimate w/ story points the top of our TechDebt backlog and place those into a dummy sprint we create named TechDebt Next.
- I started this for Sprint 51, here’s a picture.
- 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 ourtotal estimated velocity.
- When our team’s next sprint is starting, we’ll pull items from the TechDebt Next sprint into our regular **Team’s Sprint. **
- We can at this point delete the dummy sprint Tech Debt Next.
- During the sprint we can see which Jira issues are TechDebt with the Quick Filter Tech Debt.
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 ToDo. 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.
Is this the way of things now?
Yes. For Tech Debt. Lets take control of what is slowing development down the most and start fixing. I’ll be looking to step out of the way quickly once we get a good rhythm going.