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.