Skip to main content

How to deal with Technical Debt?

Last post 05:35 am September 29, 2018 by Ian Mitchell
7 replies
08:30 am September 26, 2018

There are multiple ways to deal with Technical Debt. I have highlighted a few:

•    Include more number of technical PBIs during the initial sprints. Development Team should spend time to perform technical analysis. 

•    Refer to the coding checklists and guidelines that are being followed in the organization. Follow them from beginning of the sprint. This will avoid rework.  

•    Perform Regression Testing every sprint. Automation of test cases will help here.

•    Execute non-functional testing like performance, security etc. from very first sprint itself.

•    Inspect Definition-of-Done during the Sprint Retrospective and make improvement(s) in the Definition-of-Done. 

•    If Technical Debts are identified, then the Development Team should be open and discuss with the Product Owner. Include relevant technical PBIs every sprint to pay-off for the technical debt.


09:44 am September 26, 2018

Suppose a Product Owner deprioritizes technical debt PBIs because the comparative business value appears to be low. They always seem to end up at the bottom of the Product Backlog.

What responsibility do you think the Development Team has for resolving that situation, and what alternative technical debt policies might they consider adopting?

05:54 pm September 26, 2018

 Ian Mitchell

Development Team should convince the Product Owner and highlight the implications of not paying off for the technical debt early. 

Other alternative can be to add such items in the DoD. 

Please suggest if there can be any better ways!


11:48 pm September 26, 2018


The team has the responsibility to advise the product owner about the technical debts. But the product owner has the final decision about which PBIs are priority in the backlog. Maybe the product has to be released as soon as possible and the risks overgain the debts.

Martin fowler has one statement that we have to consider:

"you need to deliver before you reach the design payoff line to give you any chance of making a gain on your debt. Often taking on technical debt ends up slowing you down so much you end up delivering later".

01:54 pm September 27, 2018

Suppose the PO was not convinced, despite the Development Team's best efforts. He or she fails to see technical debt as a significant business concern, and continues to de-prioritize technical debt items. The team remain greatly concerned that the debt being accrued will eventually sink the product.

Do you think that the Development Team still bears a responsibility to remediate (pay off) that technical debt?

03:37 am September 29, 2018

I understood your point. And i think the team has no responsibility of a probable failure of the product caused by a cumulative technical debt. Maybe the Scrum Master can help the team to convince the Product Owner to consider this in the management of backlog. Just a guess. Never lived this situation.

05:35 am September 29, 2018

The Development Team are responsible for the technical quality of the product. It is unprofessional for them not to address it when it poses a threat to the viability of the product, or the ability to develop the product in the future.

One danger of technical debt is that if it is not repaid, it can grow, as one inferior solution is added onto another, to get around an underlying problem.

The Development Team can (and almost always should) take responsibility to prevent technical decisions that preserve the ability to develop at a sustainable pace.

One tool they have at their disposal is the definition of "Done". They could build in safeguards to prevent the accumulation of technical debt.

One such safeguard, expressed in terms that could be understood by non-technical colleagues could be:

No changes are made, that make the product harder to develop.

05:35 am September 29, 2018

And i think the team has no responsibility of a probable failure of the product caused by a cumulative technical debt.

Let’s explore this a bit further. In Scrum, no-one can force a Development Team to incur technical debt, or to work on a product which they believe will eventually fail due to technical concerns.

The Development Team are responsible for the quality of their work, and for ensuring that it meets a Definition of Done which is of production standard.

A Product Owner should always expect the Development Team to “do the right thing” at a technical level, even if that means adopting a policy the PO does not currently understand or thinks to be inconvenient.

Hence it can be argued that the Development Team will always maintain a responsibility to control and mitigate technical debt, and are never absolved of that duty regardless of what a Product Owner wants to do. If the PO is unable or unwilling to prioritize debt items on the Product Backlog for example, then the team may be obliged to take the matter out of his or her hands entirely, and to adopt a different technical debt remediation policy. This could be as simple and as blunt as reserving most of their future Sprint capacity for paying off debt until the product stabilizes, and/or refusing to incur any further debt until the current liability is paid off.

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

Please note that the first and last name from your 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. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, 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 may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.