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.
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.