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?