How to manage Technical Debt?

> ...what's the best way to manage and pay it?

What importance do you think should be given to the Definition of Done in this regard?

In my opinion it's important to let key stakeholders and the PO aware that Technical Debt may result in future issues like bugs, hard maintainability and bigger time of development (consequently the reducing of team velocity), affecting areas like marketing, callcenter, etc.

Yes, you're 100% right, so technical debt should be avoided from the start. Technical debt usually accumulates as a Sprint Planning result, when developers estimate their time but forget to include clean up time for the application in general. What about Continuous Integration? Do you already know about new debt during the Sprints?

If you're already in debt and can't make for it up during the coming Sprints "by the way", I would just talk to your Product Owner, explain the situation and ask for some time during the next Sprints to get even. It's surely better to delay the implementation of one or two features than to keep adding / carrying debt. Sensible POs should agree.

I addition to Ian's remark about Definition of Done, of course.

Hello Ian and Marc, thank you so much for your time.

> What importance do you think should be given to the Definition of Done in this regard?

Ian, just to reinforce the idea in my head: The DoD must conceive the concern about not letting behind technical debts, what is the wisest approach. Maybe my question was more related to what Marc said in his 2nd paragraph, when there's already technical debt (for instance in an environment that adopted Scrum after the implementation of the product started).

> It's surely better to delay the implementation of one or two features than to keep adding / carrying debt. Sensible POs should agree.

Couldn't agree more, Marc. I just wonder when the PO is not so sensible/flexible. I could say that in this case the Scrum Master must step into the situation and let this importance clear or is it the sole responsability of the Development Team?

Thanks again.

Like you said it's important to communicate to the PO and the stakeholders, and get their acknowledgement, on the importance of managing technical debt. Without their understanding, it's going to be difficult to prioritize any tech debt item over a feature story. But once you have them onboard, there are multiple ways to manage, prioritize and close these items. The approach that worked well with the teams I have been involved with was
- Track technical debt as stories on the product backlog. You can either have each item as a separate story or club related items into one story or epic
- Allocate a certain % of capacity in each sprint to technical debt. Let the team pick and choose the tech debt stories
- If there are fewer feature stories, the team can take on more technical debt items within that sprint

Of course, you do this to catch up on the debt but having the right and evolving "definition of done" like Ian and Marc mentioned, and ensuring the team adheres to this criteria stringently will help reduce the debt the team/ product will have to deal with.

Hi Ranjith,

Nice approaches to manage the debts, thank you. Just a while after mentioning "Technical Backlog" in my first post I realized that technical debts are in essence, work to do, like any other PBI, so they belong to the Product Backlog. Adding another artefact would just complicate things.

Thanks again,
Vinicius

I just wonder when the PO is not so sensible/flexible. I could say that in this case the Scrum Master must step into the situation and let this importance clear or is it the sole responsability of the Development Team?

Ok, if push really comes to shove, just please address the stakeholders. Their money is at stake and it's in their interest to get rid of debt to avoid future bugs. There's nothing the development team could do about it without the Scrum Master stepping in.