How to handle technical debt

Have a Definition of Done that truly assures usable quality and make sure the Developers understand their obligation to observe it. They may need to take less work on if they are to be accountable for the quality of each increment. That stops any more technical debt from accruing.

Quantify the technical debt that has already been incurred on the Product Backlog and encourage the team to frame a policy for paying it off, perhaps a certain percentage every Sprint.

As I agree with everything what Ian wrote, I would like too add another perspective too percentage approach.

Basing on my experience saying that we will plan X% of our Sprint for tech debt or that we pull it into the Sprint as PBI often is wishful thinking that won’t address the problem in the long run. As tech debt may be accumulated also unwillingly, we rather should create habit throughout timeboxed event.

IMHO it is similar situation to striving to have fitness. If we truly want to do it we most likely will have a diet criteria that help us prepare right meal (aka DoD), but also we should have training plan that help us keep in check extra fat that we accumulate one way or the other, or even help us burn already accumulated one.

Therefore I would argue that as tech debt is that extra fat, and we are willing to keep our codebase in a good fitness, then most effective way is not only to change DoD or add PBI about it to the backlog, but also explicitly create routine through timeboxed event to pay off tech debt. It may be i.e such rule: “Every Friday from 10am to 4pm we focus only on paying off tech debt”. The very same mechanism that people use when they workout on the gym, no one say “I will spent 15% of my time on the gym”, everyone create routine by exactly planning out timeboxed for such activity.

I would encourage you to consider this perspective and if you will try to do it, it will be best if you entrust developers to spent that time on tech debt that they assess as most important, as they are closest to the work :)

The first step has to be to stem the tide of defects and technical debt. You won't be able to make progress on paying down the debt if you keep incurring more. Using your Sprint Retrospectives to find opportunities for improvement and talking about how to make progress on improving your Definition of Done is a good start, but you may need more. For defects, I'd recommend looking at individual defects and applying root cause analysis techniques to find the most likely root cause(s) of each defect and finding ways to prevent new defects.

Tracking your existing defects and technical debt in the Product Backlog and ordering the work can be beneficial to paying it down. You can even create dependencies or links between technical debt and new development efforts. If your stakeholders are asking for a particular unit of work, you can find defects and technical debt that are closely related. Make improvements as part of delivering that feature. You won't be able to deliver as many features as quickly, at least at first, since some of your capacity will be fixing old problems. However, once the debt is paid down, defects are reduced, and the new work is of a higher quality that doesn't have as much technical debt or defects, you may find yourself delivering faster.

I'd also point out that although defects may be greatly reduced, not all technical debt can be eliminated. I'd look at the Technical Debt Quadrants. Find ways to prevent reckless and prudent/inadvertent technical debt. You may not be able to do much about prudent/deliberate technical debt unless you are able to look at the broader context that forced you into making those decisions in the first place.

I agree with Ian, DoD is the start. 

Encourage to the team to make it as granular as they see fit. Review it with every sprint. Include items in the DoD even if they are not feasible right now. If anything in the DoD cannot be achieved then it needs to be escalated to whoever can fix it by the ScrumMaster.



Retrospectively fixing defects and tech dept is always a hard one to sell. We've tried allocating 20% of each sprint to defects and 20% to tech dept. I'd also push this one step further and ask the team that this be done at the beginning of the sprint opposed to at the end, if it's the end of the sprint then it can usually get dropped.



Add defects and tech dept to your sprint goals. 



Do RCA on defects, include this in the DoD, you might figure out where the defects are coming from.



Automate Automate Automate and get agreement that Automation test failures are showstoppers.

It is always good to understand what is TD and the causes, as soon as we identify the causes it is easy to fix.

I suggest that before you discuss tech debt with your bosses or partners and customers let's learn how to explain technical debt in plain English.

One of the reasons for the cause of TD is a pressing deadline or time constraint. These usually force software engineers to take up hard coding to speed up the process or let's say any other approach just to meet the deadline instead of the appropriate solution.

Inefficient management and poorly or ineffective designed strategy are some of the causes of non-technical debt. These may include the following factors:

- low or insufficient budget

- inexperienced technical leadership

- When agile methodologies are not well understood or applied.

I will suggest making the coding process agile.

The Product Backlog is supposed to be a single source of all work needed for the Product.  Technical debt is work needed for the Product. I encourage that all tech debt be captured in Product Backlog Items as soon as the debt is identified.  

Each item in the Product Backlog has value.  The value is negative as long as it lives in the Product Backlog and positive when it reaches Done.  The Developers have to help the Product Owner understand the value associated to the tech debt items so that the Product Owner can appropriately order the items in the backlog.  Remember that the Product Owner is responsible for maximizing the value of the Developers work.  Sometimes tech debt can provide more value than a new feature.  For example if marking a tech debt item Done will allow the Developers to provide new features faster and reduce the on going maintenance effort of those features, it would be easy to make the case that the tech debt item is more valuable to complete.  

Try not to treat tech debt any differently than any other Product changes.  Make it visible, treat it in the same manner, maximize the value being delivered by the Developers by having them work on the items that have the most present and long-term value.  

Having technical debt is not a good thing but it also does not mean all of it should be addressed. Consider the case where there is some refactoring that needs to be done on a feature that has no near term work identified.  The tech debt could wait until a time that new work is needed on the feature and be addressed then.