Skip to main content

How to manage Technical Debt?

Last post 12:16 pm June 6, 2016 by Marc Smeets
6 replies
06:59 am June 6, 2016

Hello guys! First post here, I hope you all are doing great.

Starting from the point that Scrum doesn't have technical sprints ("hardening sprints", "cleanup sprints", etc) to pay technical debt, what's the best way to manage and pay it?

Outside Scrum, I read about a "Technical Backlog", that would contains issues to be paid, but how could this fit in Scrum? How to continuously pay technical debts and deliver feature value at the same time?

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. How to balance technical value and feature value?

Thanks in advance!
Vinicius Abreu


10:56 am June 6, 2016

> ...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?


11:35 am June 6, 2016

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.


11:52 am June 6, 2016

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.


11:56 am June 6, 2016

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.


12:04 pm June 6, 2016

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


12:16 pm June 6, 2016

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.