Home > Technical > Technical Debt Wall Retrospective

Technical Debt Wall Retrospective

September 1st, 2009

Although we should avoid as much as possible Technical Debt, most of the projects end up incurring some of it. However it is important to know “how much” we owe and how much interest we are paying.

Know your debt

Recently on our project we did a Technical Debt Retrospective. Basically we brainstormed on the wall all the Tech Debts we thought we had incurred since the beginning of the project. Then we decided to categorise them by Effort and Pain:


“The relative effort that the team would have to spend in order to pay this debt.“

Pain is the direct impact on productivity that this debt causes. (interest)”

Keep paying down the principal, not only the interest

If we do not pay down the principal of our debt by refactoring our code we will always be paying just the interest, which means reducing the productivity. The question we asked ourselves was “Which ones should we pay first?”

Looking at the four quadrants of this wall we can identify which ones we can pay so that we can have the highest return.

TechDebtRetroEffortVSPainHighReturnNotWorthOne interesting thing that came out of our retro was that the High Return section was almost empty. We came to the conclusion that this was a good sign, it means that we had already fixed most of the LowEffort/HighPain debt during the normal development. Which is exactly how this type of debt should be paid.

After the retro we kept the Technical Debt Wall next to our Story Wall. From that day on it should become an ongoing wall that we will keep an eye on… Paying whenever possible…

Technical , ,

  1. September 1st, 2009 at 14:37 | #1


    I’ve done a very similar thing on my previous project. The difference was that I used “value” instead of “pain” on one of the axes. I guess I prefer your approach better, because it’s easier to answer “Which item is causing the most pain?” instead of “Which refactoring would provide more value?”

    Another interesting thing that was helpful at the time was using coloured-coded post-its for each functional area of the application (so you could see which area needed more attention). It was also nice to do the same exercise after some time to notice the difference. I will try and chase my notes/pictures and might write about it if I find them.

    I guess great minds think alike :-)

  2. Gary Thompson
    September 5th, 2009 at 08:15 | #2

    I will be sending this post to my team Monday. Great explanation, I had a different take on this in February this year regarding a balance of technical and financial debt - http://blog.thompson-web.co.uk/2009/02/technical-debt.html

  3. Dumitru
    September 29th, 2015 at 01:12 | #3

    Almost 6 years later, I’ve done a similar thing in my team, without ever seeing this article. Can’t believe how similar it was!

    I’m doing test automation, so on my project I had one more thing, a vertical line about 10% in, that was the “blocker line”. Anything before it had to be done regardless of the effort required.

    The outcome was similar to yours. Although everyone was complaining about how much stuff we need to do, how much debt we had. After the meeting it became clear there was almost nothing from debt that required our immediate attention

  4. September 29th, 2015 at 03:45 | #4

    I’m glad you like the post Dumitru. I’m glad we came up with such similar solutions for the same problems from different parts of the world. Thanks for the comment

  1. October 26th, 2009 at 06:11 | #1
  2. December 22nd, 2009 at 14:28 | #2
  3. January 18th, 2010 at 15:52 | #3
  4. January 19th, 2010 at 23:44 | #4
  5. July 13th, 2010 at 12:51 | #5
  6. June 19th, 2011 at 05:16 | #6
  7. August 21st, 2011 at 10:34 | #7
  8. September 19th, 2011 at 23:50 | #8