On integrating technical debt in your sprint planning

Managing technical debt in a SaaS can be quite challenging. On top of development best practices your lead developer should enforce, as a product manager you can organize your planning so the team effectively dedicates some time to refactoring, package updates and documentation. And that’s via giving a clear timeslot to maintenance.

Adding maintenance weeks to your planning

Some companies dedicate a day per quarter to handle technical debt, others integrate it within their sprints. I like to plan a dedicated week for it, as developers provided the feedback that a day is not enough to handle bugfixes and that having those during the same week as integrating new features just doesn’t cut it.

We collectively decided to implement a week of maintenance in between each sprint.

By separating new features and tech debt, we effectively ensure a coherent release process and can be sure bugs will be fixed by the end of the month. This allows us to de-prioritize bugs when they arise. If they’re not a high-priority, high-impact bug that requires an immediate hotfix, we can rest assured it will be taken on quickly.

This allows the dev team to be less stressed. And a less stressed dev team is a better engineering environment and that leads to happy devs 😄

On the product management side, keeping a dedicated week to maintenance tasks ensures they get done. That way, you can circle back to Customer Support with confidence that the bug they just reported will be handled soon.

Debt tech management best practices

Have a dedicated board where you can stack all the tech debt issues you and your team may encounter. These can be added in a Kanban board and prioritized so you always know which bugs will be handled in your next maintenance week.

• Keep it separate in a dedicated view in your beta project in Github
• Create an issue as soon as you see a bug
• Assess the impact is has on your infrastucture, your team or your users, count how many users have been reporting the bug, link to the customer support conversations if there are any.
• Evaluate the engineering effort it would take to fix
• Prioritize

Continue your research:

Learn more about the impact of tech debt with Gergely Orosz, AKA the Pragmatic Engineer.