“Debt” is not a pleasant term. It brings to mind a burden and generates a feeling of anxiety. The same may also be true for technical debt, or the extra work that we incur while developing our software in the form of missed quality targets, pending tasks, or skipped points from our exit criteria checklists. Like monetary debt, technical debt happens when we make a decision that is quicker in the short term but will hurt us in the long term.

Though we may try our best to limit this debt, it will still happen. And while we will need to pay back the debt one day, we can also use it as a lesson to help improve ourselves and our processes. If it ultimately helps our development, it doesn’t even always have to be a bad thing.

In my article published on the Ranorex blog site, I examine three ways technical debt can actually help us improve our sprints.

Better Estimation

Though the first time incurring technical debt due to an inability to complete an activity as planned may not be pleasant, it should consequently improve the team’s estimation and planning.

Let’s say we had defined developers’ tasks for all user stories with estimated hours, along with a mandate of peer reviews being performed for all code being written. But the end of the sprint saw that though the developers marked their development tasks as done, none of the code had been peer reviewed before check-in. It could have happened due to lack of time or ownership.

The next sprint, the team then decides to have a separate sub-task for peer reviews under the development tasks, each of which is assigned to a peer with an allotted time of 30 minutes. This helps the team plan, have clarity around what tasks are pending, and see how much effort is being spent on the tasks.

So, even though you may begin to accumulate technical debt early on in your sprints, understanding the cause and having a plan of action may improve the team’s overall performance.

Sequencing and Prioritizing

If you find yourself at a point where release is a couple of sprints away and you have a number of unresolved defects, even though they are lower severity, the team may decide to reduce open defect counts for a sprint rather than adding new features. The technical debt incurred in the form of defects can urge the team to refocus and shift priorities.

Or, let’s say your team agreed to 70% automation of regression testing in the beginning of the release cycle, but after four sprints, the scripts they created are showing signs of being unmaintainable or not scalable enough. This may affect delivery in the end, so some testers may take the call of focusing full time on reworking the scripts and adding new automated tests to them, while the other testers take up functional and regression tasks.

My team once found out at the end of our fifth sprint that our developers had not been performing static analysis of their code or creating the reports that were mandated for every sprint. Whatever may have been the reason, this meant that running those reports now was leading to hundreds of errors or warnings all pertaining to code formatting, naming conventions and comments. Even though these were minor issues, it required time to get them all corrected with thousands of lines of code.

What happened next??!!! Read the complete article here to find out!

Of course, any decisions made should be based on context and business intent. But having these kinds of problems due to technical debt makes the team grow stronger as a unit, because everyone has to take ownership and help out their coworkers. Over time, the experience also should make them better at prioritization of tasks.

Hardening Iteration

Though not ideal, a hardening iteration can be used to pay off some technical debt. So, having a plan for a hardening iteration in the beginning can be a savior for the team in the end, in case they end up with a bunch of pending items.

If you had no real action plan for your hardening iteration, the first place to look at is your technical debt. Items like pending automation tasks, document reviews, improving white-box test coverage, or any exit criteria that was missed when completing a task or user story will be the first goals to target.

Added with functional regression tests and automated test runs, this action will bring the team more confidence in the system. It can make the release time less stressful and put everyone on the same page.

Make the Best of Your Technical Debt

Technical debt is not pleasant, and it should never be the goal, but it can provide many lessons in the way the team acts against adversity and works together in resolving it. Tackling technical debt can help the team improve and make their sprints better over time. So, take a deep breath and get on top of it!

Read the complete article here to find out how to make the best of your technical debt!