How we manage tech debt

One of the most beneficial and, dare I say, favorite meetings of the week is our tech debt meeting. I've been considering writing this for a while and that vigor was renewed when I read a LeadDev article on the topic that spoke to the elements of my team's tech debt process. The LeadDev article calls out categorizing, creating time to talk about tech debt, and prioritizing efforts. Here's how my team (and other teams in the past) does that.

Create the space

When it comes to sorting through ideas, I prefer a visual medium especially if we have to categorize and prioritize. For this, our team uses Lucidchart and previous teams I've been on have use Miro.

On the left is where we put new items in the form of sticky notes. It may be good to include the name of the person who is adding the note so that if it's especially complex or it's presently siloed knowledge, the team knows who wrote it. Also, sometimes you from the future forgets what you from the past wrote and why.

In the center there is a quadrant. The y-axis is a general feel for the positive impact of a piece of work and the x-axis is the amount of effort required to do the work. This results in four sections with shorthand names:

• Low effort + high positive impact aka "just do it" (upper left): This work will be completed next time someone is in that area of code.
• Low effort + low positive impact aka "if we get to it" (lower left): This work isn't really worth the effort but if we happen to get to it, then we'll do it.
• High effort + high positive impact aka "make a story" (upper right): This is work that requires tracking either for auditability because we want to be able to look back and see why and what we did, and/or because it's a substantial effort (typically our heuristic is more than 30 min should require a story).
• High effort + low positive impact aka "the recycle bin" (lower right): As work and priorities shift, this may become higher impact work, however, at the time it is classified it requires a fair bit of work for little benefit so it goes to the recycle bin.

Finally, on the right side of the space is the done/addressed box. We keep all of our cards because as we work on them we keep notes about discussions we have as the card moves through the process. If work lands in the "make a story" quadrant, once the assigned person makes the story, it moves to done/addressed.

Standing meeting time

Every Monday we spend 30 minutes going through our tech debt board. One person is the facilitator of the meeting and this responsibility rotates throughout the team. Sometimes we start with the new column and sometimes we review the quadrants to move anything to done/addressed that needs to be moved. Typically, we'll review the "make a story" and "just do it" sections every week and the "if we get to it" and "recycle bin" sections ad hoc maybe once a month.

The facilitator is responsible for keeping the meeting flowing. A few pitfalls to watch out for:

Solving the problem: It's very easy to fall into the trap of trying to solve a problem when you're discussing it. Remember, the objective of the meeting is just to decide how the problem will be handled - once you've got that, move on to the next thing.

Scope creep: It's easy for discussions to start to get into other problems the team sees or things they've been meaning to talk about or address. Keep an ear open for when conversation starts to drift and suggest creating a new card or another avenue for discussion like stand up, a tech huddle, or team norms meeting.

Time: Be mindful of time. If you still have cards to talk about when the allotted time is up, that's ok. Typically, we've seen an ebb and flow of how many cards we address and how many are left on the tech debt board in the new column. If the list is only growing, this might be a good time to think about either increasing the length of the meeting or the frequency. Also, working in the opposite direction, cutting the meeting short is great. Reducing the length or frequency is a good adjustment if you find you're running out of tech debt to talk about.

What's Next?

Once the tech debt becomes a story, it's paired with a feature so that it doesn't just go into the backlog and die. This ensures it does get prioritized and we allot 2-3 cards per sprint to tackle tech debt. If it's a "just do it", we talk about what work we're currently doing and who might be working in the area of code where that work needs to be done.

That's it! If you have questions, hit me up on Twitter @weberswords.