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

  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