Technical Debt in Scrum - How to Pay Them Back

A lot of Scrum teams face the challenge of balancing the implementation of new product features and keeping the code base clean and maintainable. Very often the product owner pushes the development team to ship an increment with new features at the end of every sprint. The development team might not find the time to keep the code base clean and maintainable. With every refactoring that the developers feel a need for but that is not done, the team increases its technical debt. If the technical debt is not payed off, it will slow down the team's productivity in the long run. In this post I propose a way of balancing the implementation of new product features and the reduction of technical debt.

A Scrum team pulls work off the product backlog (PB). The PB is maintained by the product owner. To enable the development team to work on new product features and the reduction of technical debt

I propose the use of another backlog: the technical debt backlog (TDB). The TBD is maintained by the development team. Every time a developer feels the need for a refactoring and is not able to do it, she adds an item to the TDB. The development team gets together at least once per sprint to groom the TDB. They present the items to each other, estimate and prioritise them. The estimation can be done with the planning poker technique. During sprint planning 1 the team pulls items from the product backlog and the technical debt backlog.

The use of a separate backlog for technical debt has the following advantages:

• technical debt is visible to the development team and the product owner
• the reduction of technical debt is seen as part of product development
• the development team is engaged to increase the value of its code base

What is your approach to reduce technical debt? Or even better: how do you avoid technical debt?

Recommended Start-Up Books

Hi folks,

if you ever wanted to found a start-up and are still looking for some advice, I recommend the following three books that helped me to sharpen my understanding of a start-up's basic building blocks and it's inner workings.

The first one is Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers. This book will help you to define your initial product vision in terms of a business model. This books introduces you to a tool called the Business Model Canvas (BMC). The BMC will guide you step-by-step through the creation of a business model. Once you have defined your business model with the help of the BMC, you will find it much easier to communicate your business model to others and have a good starting point for your start-up.

The second recommended reading is The Lean Startup by Eric Ries. Eric introduces you to a methodology - the Lean Startup Methodology -  which describes how you should run your start-up. While the Business Model Canvas is used to define your start-up's business model, the Lean Startup Methodology describes how you should implement this business model: incrementally in short iterations. It will help you in managing your precious time and money before running out of them. If you have never run a start-up before, you will find a perfect coach in Eric.

Ash Maurya combines the Business Model Canvas and the Lean Startup Methodology in his book Running Lean. He presents an adopted version of the Business Model Canvas called the Lean Canvas. He shows you how to apply the Lean Startup Methodology in conjunction with the Lean Canvas. The two previous books teach you the tools. This book shows you how to use these tools. Ash takes you through the development of one of his start-ups step-by-step. He defines a Lean Canvas and walks you through the complete implementation of an initial product vision. If you have read "The Lean Startup" and cannot wait to apply the Lean Startup Methodology, read this book before you get your hands dirty.