Chronicles of a Scrum master #17 : Technical debt and Support tickets

In agile way of working, technical debt is still present as the team goes about completing stories based on definition of done.

What then exactly is technical debt ? This is the accumulation of previous known anomalies, which were not discovered previously before release. It can be in the form of bugs, design changes, code logic and even hard coding of parameters or values.

Technical debt usually has workarounds that satisfies the objective of the release without compromising the quality of the product. However, as time goes by, more and more issues / requests raised maybe related to one of the technical debts which may then need to be fixed.

It can be caused by multitude of reasons, some of which I will highlight and explore some examples below.

1. Shortcuts taken to meet deadlines : One of the examples would be system related configurations are kept as parameters in a database but sometimes this is easily forgotten as a nifty way to allow users to have self-service maintenance screens, rather than having everything done by the system administrator. Not important at first but as time goes by and more tickets come in for the team to configure these parameters, then its time to see if building this maintenance screens / pages is worth it.

2. Lack of knowledge or experience : Hard-coding pieces of functionality that otherwise could have been made more dynamic or placed into a centralized library is one of the common examples. This could be due to lack of expertise or experience and is commonly made by those junior members of the team. Hence, it is important for the team to perform peer code reviews, understand how the pieces of code came to be and how it can be improved on.

3. Poor design decisions : Scalability and adaptability is one of the direct impact of such design matters that pertains to the product. For example, in the initial stages of the product, it can be assumed to support a certain number of users. Once the use of the product became popular, the number of users may grow exponentially and result in decreased performance. Hence, the decision would be either to examine certain parts of the product, rebuild or enhance it further to ensure that the product can grow further to support more users. This can be in various forms such as monolithic vs micro services architecture, storage allocations, development framework etc.

What is the impact of accumulated technical debt ? While it may not have a short-term impact, but as time goes by, this can become a significant impact which will results in increased maintenance and complexity, reduced performance, inflexibility and higher risk. In the end, if left unaddressed, it can become unmanageable and result in poor product quality.

In Scrum, technical debt can be managed in a few ways :

  1. Prioritizing is an art and science : Based on past factual results and desired outcomes, address the technical items that are deemed critical without waiting too long. Discuss it with the technical team and determine the best route and effort to resolve it.
  2. Regular review and code refactoring.
  3. Training and development opportunities.
  4. Regular retrospectives.
  5. Technical debt items and tasks are converted into actual user stories.

In summary, increased and accumulated technical debt may result in degradation of the product quality in many ways. Hence , even if it’s not being addressed immediately, this should be kept in view in a list such as a Kanban board and be examined from sprint to sprint to evaluate and determine whether the resolution of some of this technical debt will result in a better product tomorrow.

Here are some other references to technical debt if you wish to know more :


Disclaimer: What I am sharing is purely from my point of view and experience working with various teams as a scrum master. It does not reflect anyone else’s opinion or endorses a framework.

What I present in my posts doesn’t necessarily mean that it is applicable to your work, organization and culture but I am glad if it aids you in your agile journey.

Sincerely and with many thanks for reading my articles, Jason.

Agile Scrum master

Chronicles of a Scrum master #16 : Definition of Done (DoD) Part 2

Note : This is a continuation of my Definition of Done (DoD) Part 1 here. 3. Quality The important assessment of a story after its development or work that needs be done is completed (may not be Done yet) is the quality of the work that is produced. This is usually performed by the QA […]

Read More
Agile Scrum master

Chronicles of a Scrum master #15 : Definition of Done (DoD) Part 1

What is a story that is considered done in a sprint ? Each scrum team may have their own version of the Definition of Done (DoD) for each story as long as they agree on the common concept as a whole (from product owner, business analyst to scrum master, developers and testers. It is essentially […]

Read More
Agile Scrum master

Dec 31 2022 – End of year Scrum master chronicles : Agile implementations

Alas, we are reaching the end of 2022 in a matter of days 🙂 Here in this last post of my 2022 scrum master experience, I would like to thank all my fellow readers and wishing everyone a Happy New Year in advance and may your new year resolutions be made real. Going back through […]

Read More