Now that you convinced your product owner to allow you to have technical debt sprint, what should you do in those anyways? Let us get into product owner’s shoes and think what to expect from and after the technical debt sprint. Product owner wants the team to build stories with a higher velocity or at least sustain the velocity. So, what kind of activities the team should do in the technical debt sprints to achieve this goal.
Some of the areas I see as candidates for this sprint. Are:
You might have left some unused code in the system or an unused database column is still lying around or you really want to re-factor some code that is bothering you. I am sure you could come up with a long list of these pain points, which would come in your way any time you are working in that area.
Same rules apply to testing debt also. This could include reorganizing the tests, remove unused tests and any test changes associated with code changes. The goal is that the most of these pain points are gone and the code looks cleaner and maintainable at the end of the technical debt sprint.
My team is in a technical debt sprint currently and some of the items they chose to work on are:
- Re-factor enums to have consistent lookup() method. In some enums it spelled as lookUp().
- Delete unused legacy code. We weren’t sure before if that is being used some where due to lack of automated tests.
- Remove the last piece of legacy code from a module. This required some coding in the new code base, however allowed us to removes 1000 lines of code.
- Re-factor certain areas of acceptance and web tests.
- Remove a database column from the table.
- Rename a database column in several tables for consistency.
Many QA automation services say that sprints are very well suitable for upgrading your third party software. This will allow you to start using the latest and greatest features of that software. On the other hand if you don’t upgrade the software for too long, the version you are using may not be supported any more. You need to make sure that all the dependent software is upgraded together which could require significant time.
Build features those reduce supporting activities.
The time spent in supporting activities basically not used for any features development. This supporting activity could be anything that requires your time, depending on your current situation. If you build a little features that will reduce the support time, that would be a great thing to work on in these sprints. This will allow you to spend more time on new development and will improve the velocity. Some of the tasks my team is looking at in the current technical debt sprint are:
- There is a long running process that doesn’t send any “Completed Notification” to users. Every time user needs to ask the engineers about the status of the process. Engineers are adding a feature to send an email to users at the completion of the process.
- Recently some reports were taking way longer to show up and causing production support tickets. Engineers picked up those reports to tune.
You need to be careful in picking up these tasks, since some of them could be very big and could take up the whole sprint. Team needs to look at the ROI on each task they are going to work on.
Do you have enough time?
Now you know what are the various things to work on. But your time is limited and how do you make sure that you will get maximum ROI? There will be few mandatory tasks those you have to address in this sprint. This could be upgrading a third party software which you delayed enough that you can’t delay it any more etc.
For the rest of the tasks, consider the following aspects:
Utility or Value : How valuable is fixing some thing would be? The fix could affect only one area of the system. This could be useful but the value is limited since that will help the future development/maintenance in that part of the system only. On the other hand, if the fix is going to be in a framework which is used through out the system, the benefit would be lot more.
Effort : Another aspect is how easy or hard to perform the task. Some tasks might take few hours while others might take the whole sprint. You need to be smart in choosing what you want to work on. My general guideline is to work in the following sequence, which is the combination of the two aspects mentioned.
- Easy and High Value.
- Hard and High Value.
- Easy and Low Value.
- Hard and Low value.