Get certified - Transform your world of work today


Managing Technical Debt in Agile World

29 August 2017

Having spent close to a decade in the IT industry, I have heard different opinions on how to deal with the technical debt that is accumulated over the course of feature development. With Scrum implementation as a key focus, the team's goal is always quick shipment of a new product or feature. However, in attempting to accomplish this consistently, system stability may be compromised. Many organizations forget that, as they keep piling on one feature after another, the system must scale to ensure a stable platform.

I want to share one of the ways that I have been able to find a middle ground to ensure that debt and similar technical enhancements get their fair share of attention during feature development.

During each sprint, we dedicate an n% — typically in the range of 10–20% of the work — as a ballpark of work that is picked up that belongs to technical updates. This percentage usually varies, depending on the requirement and its priority.

This estimation serves multiple purposes for the team:
  • It helps the team identify any technical impediments needed to onboard a particular feature.
  • The technical update is not delayed until late; it is an ongoing activity.
  • The team always feels that they are able to contribute not only to features but also to the technical aspect of the overall product, which is something that excites them.
However, implementing the above is not as easy as it seems. There is always a push from products of competing priority when implementing a feature vis-à-vis technical debt. To ensure that none of the priority items are compromised, continuously review the prioritized backlog for both the product and technical implementation, so that there's a trade-off and implementation of either can be planned.

Also, this involves coaching at all levels to ensure that everyone understands the importance of both the product and technical debt, because to achieve a successful product feature launch, the two go hand in hand.

Technical debt can be a crazy problem if you fail to plan for it, resulting in an increase in the overall cost of the project. So this brings me to an interesting question: What is the true cost of a product feature implementation? Is it only the total time, points, or effort to deliver a particular feature? I would humbly say no, because the cost must include technical debt, which must be resolved eventually. As well, the technical upgrades must be done pre- and post-feature implementation to ensure that, from a business perspective, there is delivery of the value that has been aimed at from the start.

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: 3.4 (5 ratings)


Tim Baffa, CSM, 8/30/2017 3:56:12 PM
A team practicing Scrum should not have quick shipment of new features as their goal.

A team practicing Scrum should ensure that all of their work meets the established Definition of Done, and therefore does not introduce technical debt.

In Scrum, there is no "piling on" of products/projects that need to be finished. Scrum promotes an honest evaluation of capacity, and a truer recognition of what can actually be forecast/completed within an iteration.

I do like the idea of allocating a certain % of sprint capacity to address existing technical debt, but in my mind this is existing tech debt, and not anything introduced through current sprint work.

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