A technical retrospective

Over the years of working with many teams, I’ve done tech retros (biweekly) and found them helpful. It’s like a sprint retrospective but focused primarily on technical debt and code issues. Here’s how it works:

We create a Trello board to which engineers add stickies with architecture/design/code parts that slow them down or make them frustrated.

At the tech retro we:

• Review, clean, and prioritize the list.
• Agree on who’s fixing what during the next 2 weeks.
• The next retro begins with reviewing the results.
• Repeat.

We cap the list to ~15-20 items. The limit represents how much we can actually handle in a few months ahead. It feels much better and also more effective than maintaining an inventory of 1000+ items, most of which will you’ll never have time to do anyway.

Don’t be afraid of dropping items; if something is important – it will return.

In the end, you have three types of tech work:

• Technical work as part of a user story/business problem.
• Technical work you can do when you have time/slack/buffer (tech retro work).
• Continuous refactoring (aka The Boyscout Rule) is part of the coding process and need not be planned.