Engineering Blog
BackFrom Retro Frustration to Tech Debt Clarity: How We Prioritize
Want to learn how our development team tackled the common struggle of prioritizing tech debt and what it has to do with beers and our next vacations?
The Problem: Everything Feels Important
During our regular retrospectives, we frequently encounter various tech debt issues, such as bringing up older code to our current coding standards and style, overly complex code that could benefit from refactoring, and libraries that require replacement or upgrading.
As engineers, our instinct is to want to fix everything – it's in our nature. But with limited time and competing product priorities, we needed a better way to decide what actually deserved our attention first.
The Solution: A 4x4 matrix
That's when we decided to dedicate a focused workshop session to really understand our tech debt. I'd recently come across an idea from Dave Farley's "Modern Software Engineering" YouTube channel in his video "Why Software Estimations Are Always Wrong," and thought we could adapt it for our needs.
The concept is simple: a 4x4 matrix that frames tech debt prioritization through two key questions:
- Y-Axis (Value): How much would you pay a colleague if they solved this issue?
- X-Axis (Cost): How much would you want to get paid to solve this issue yourself?
Rather than falling into traditional estimation methods, we embraced deliberately imprecise but universally relatable categories: a beer, a vacation, a car, or a house. These rough buckets allowed the team to make quick value-versus-cost comparisons without getting caught in the false precision that typically derails prioritization discussions.
Setting Up the Workshop
We gathered the entire development team. I prepared a large 4x4 grid on our virtual whiteboard, with "beer" to "house" marked on both axes. We initially started with the same layout orientation shown in Dave Farley's original video, but after working with it for some time, we found we needed to change the approach. We switched to positioning the origin (0,0) a.k.a. (Beer,Beer) at the bottom-left corner – the standard Cartesian coordinate system we're all familiar with. This conventional layout proved much more intuitive when working with more than a few stickies.
Each team member wrote down tech debt items on sticky notes, and we placed them on the matrix based on our collective assessment. The discussions that emerged were incredibly valuable.
The Results Spoke for Themselves
What emerged was a clear visual representation of our priorities:
- Top-left: High value, low cost – our obvious quick wins
- Bottom-right: Low value, high cost – items we should probably ignore
- Bottom-left: Low value, low cost – nice-to-haves
- Top-right: High value, high cost - Strategic investments worth planning for
Beyond Prioritization: Building Shared Understanding
The workshop's real success wasn't just the prioritized items we created. It was the shared understanding we developed as a team. We had honest conversations about complexity and about the pain points we each face daily.
As an additional advantage, the resulting matrix serves as an effective tool for communicating with stakeholders, facilitating discussions about the trade-offs between competing priorities.
Lessons Learned
Sometimes the simplest tools are the most powerful. A few sticky notes, a virtual whiteboard, and some beer-to-house analogies gave us the clarity we'd been missing for months.
There is just one final thing I need to note: none of our developers actually owns or wants a car. Maybe we should go with a beer, GA Travelcard, a vacation, or a house next time ;-).
If you have comments or corrections to share, you can reach our engineers at engineering-blog@cloudscale.ch.