Get certified - Transform your world of work today


Reducing Technical Debt

Striking a balance between product innovation and technical debt

28 August 2015

Ramesh Lakkaraju

Organizations must often decide whether to release a product earlier to accelerate the time-to-market factor or to release the best, smartest solution that has no open or pending issues but might take longer to release to market. They need to strike a balance between these two choices and design a plan for a quality release with the best time-to-market factor. In doing so, organizations may tolerate living with some of the known issues that might not be a priority at the time but have to be addressed in the long run. Known issues that remain in the backlog in the form of unfinished work are generally called technical debt. In simpler words, technical debt is the difference between what was initially envisioned and what was actually delivered.

Technical debt depends heavily on whether it is associated with a new start-up project or with legacy products. Mature products have a lot of accumulated technical debt. Not all of this debt was deliberately added; it could be the result of simply not having anything better at the time the product was originally built. Typically, this accumulated technical debt for legacy products forces organizations to spend considerable time in reducing it rather than focusing on new feature development. This indirectly reduces the appetite to work on those new features that are crucial to keeping the business abreast of the latest market requirements and trends and also to remain competitive in the market.

Managing technical debt is critical to organizations with large code bases to make their products successful; they must handle a balancing act of keeping existing customers happy and attracting new customers. They must convince prospective customers to buy their products by either coming up with new features or enhancing existing features. If not properly planned and managed, technical debt can become a major blocker that can affect the organization's reputation in the long term and can have a huge impact on the existing and new customer bases. Technical debt plays a vital role in the ability to attract new customers, as they will always want to buy a product that is free of it.

Although different organizations adopt different strategies for dealing with technical debt, experience shows that the most successful way of tackling it is to budget for it in the release and in the iteration planning, as with any other budget. Quality metrics (e.g., trouble reports) collected regularly from customers can be an important factor when deciding how much of the total capacity must be reserved for technical debt reduction. Having a specific technical debt "bucket" in the product backlog, and addressing, it will certainly add value to customers in the long run.
One effective way to control technical debt is to prevent further accumulation. This is accomplished by creating buckets by estimating the average rate of debt discovered in the previous release cycle. This way, if the incoming rate of technical debt remains the same in the current cycle, the reserved bandwidth would ensure that the technical debt does not increase further.

In addition to focusing on reducing accumulated debt, organizations might encourage teams to develop a process in which a review and an update to the Definition of Done is done regularly to prevent the accumulation of debt in the first place.

After having decided to reduce or eliminate technical debt over time, organizations face another major challenge: prioritizing it. Any technical debt reduction must be justified. Is it worth the effort and does it really benefit the customer, or does it increase business prospects for the organization? A good strategy from product management is essential in evaluating true debt versus structural improvements. That way, the strategy can be effectively prioritized for giving the highest value to the organization today and in the future. A variety of items, such as enhancements to existing functionality or changes to the underlying architecture, can surface throughout the project's life cycle, which may seem important from the developer's perspective. Product management must therefore constantly strike a balance while prioritizing these items, to determine whether it's necessary to pull an item into the backlog or whether it can wait for some time.

It is difficult, if not impossible, to remove all technical debt, especially in organizations that have a high volume of legacy code. Given today's highly competitive market, and to ensure the organization's long-term success and survival, product managers must have a clear road map that includes a sound plan for simultaneous investments in both innovation for new features and improvements to existing products.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.7 (3 ratings)


Robert Day, CSM, 9/1/2015 4:41:44 AM
Good article, Ramesh. The project I've just been engaged with accommodated technical debt in the development phase by allocating a given amount of time in each sprint for bug fixes; but of course, not all bugs were considered sufficiently critical to be fixed in the subsequent sprint, and so less critical bugs became accumulated technical debt.

We dealt with that by having a defect fixing sprint at the end of the project; but even then, we had to decide which bugs were more critical in order to prioritise them - so we were still left with some technical debt after the defect resolution sprint.

Add to that the way that the business kept coming up with new "enhancements" that they only realised the need for once they'd started using the application, and you can see how technical debt accumulates in the real world!
Ramesh Lakkaraju, CSM, 9/3/2015 1:32:40 AM
Thanks a lot for the comments Robert.
Nice to learn that you have a good process to reduce/contain the technical debt. Yes. You are right. Not all the technical debt can be removed and it is very much essential to prioritize in cleaning up the accumulated debt.
Arvind Kaul, CSM, 9/8/2015 3:06:31 AM
Interesting article, even if everyone realizes the need of reducing technical debt to have a stable product more often than not it gets overlooked as we are bombarded with new enhancements..and on times new enhancements add to the existing technical debt. We have had some success to avoid adding technical debt or keeping it in control by driving development team(s) to follow clean code practices.
Ramesh Lakkaraju, CSM, 9/10/2015 1:50:50 AM
Thanks for your comments Arvind. Yes, you are right in saying that having clean code practices in place will avoid adding more technical debt. I have touched upon this point in the paragraph mentioned of the article..
"In addition to focusing on reducing accumulated debt, organizations might encourage teams to develop a process in which a review and an update to the Definition of Done is done regularly to prevent the accumulation of debt in the first place."
Deepak Gupta, CSM, 2/17/2018 9:26:34 AM
No matter what, everybody has to pay the price of debt. Either at a regular pace in each and every sprint or have a separate sprint to release that debt. But yes, debt must be removed to be successful in the market. Earlier the better so that you won't get buried in the debt.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up