Technical Debt – Steve Novoselac's Blog

Agile: Tech Debt Sprint

In software development, the biggest thing you can do for the users of your product is deliver value. Adding business value is critical to maintaining a good product and keeping users happy. But there is another group you need to keep happy as well, and that is your development team.

Technical Debt (think of it like real money debt) is the extra WTF’s that add up in your codebase over time. You add a new feature, and take some shortcuts, you say “we will fix it later” but later never comes. You end up with untested (Unit Tests/Developer Tests) code and with “legacy code” that is hard to maintain. How do you get rid of all that? You have to pay down your debt, that is where Tech Debt Sprints come in.

Just like paying down regular debt or even how people keep regular debt, you usually have some. People have mortgages, or car loans, that they pay down. So in any app you end up having tech debt, but you need to keep paying it down instead of just adding more and more debt, because sooner later you’d have to declare technical bankruptcy, which is no good. (Close Shop? Rewrite? etc).

What I like to do is balance tech debt in two ways.

1. First, in every sprint, there should be a percentage of points dedicated to technical debt. 15-25% is a good number.

2. Second, every X sprints you should flip that percentage. So if you usually do 70% enhancements, 10% bugs, and 20% tech debt, every 4-6 sprints, you should flip it around: 70% tech debt, 10% bugs, and 20% enhancements. I might most later on the concept of another type of sprint, a “Hardening Sprint” where you dedicate 70% to just bugs to “harden” your app.

Now, you may have to negotiate with your Product Owner, which after a while they might get high on the drug that is enhancements and business value. Most reasonably Product Owners though, will realize that the code and developers need to pay down tech debt to make the overall application better and also make it easier to get future enhancements to market faster.

You may even get some stories that I like to call “Trifecta” stories. What are they? Well it is that “magical” story that satisfies three causes, Enhancement, Bugs, and Tech Debt. An example might be a crappy custom control that you’ve had in your app that you can replace with built in functionality or a better architected 3rd party control. Users will get the added functionality (enhancement), crazy bugs from your custom code are gone (bug fixes) and tons of crappy code is just dropped from the codebase (tech debt). Everybody is a winner!

I blogged previously on using User Voice to track your tech debt items at a higher level and have devs vote on them, it works somewhat, better than nothing. Usually stories come out of each “idea”. The bottom line though is to make sure you dedicate time and effort to paying down your technical debt. Far too often dev shops ignore this or always put it off till some mythical “later” that never comes. You need to just do it. It will make your code and app better, your devs happy, and keep things moving forward.

UserVoice: Using A Customer Service Tool To Democratize Technical Debt

Not sure if you anyone has heard of or used “UserVoice” – It is a site that allows you to create “forums” for your products and then submit ideas, give users votes and they can vote them up, and an admin can say things are started, merge ideas, or mark when the idea has been completed (and the votes go back to the users).

UserVoice is (sorta) along the same lines as GetSatisfaction (another cool customer service 2.0 app). Pretty cool tools. If I was in a customer service role, especially with any type of user based or public product, I would be running these tools to gather ideas and feedback from my users.

I am in a technical role, so what I decided to do was “democratize” the development area of our product one of my teams is working on. We have a ton of technical debt (as do most teams, it is just a matter of what level of debt you have) – but what should we work on next from a technical perspective?

In comes UserVoice. Let’s throw out ideas on UserVoice, give everyone 50 votes, and the ideas that bubble to the top will become our next set of things to work on. One “idea” may become several “user stories” (we are agile). Our goal is to have 20-25% of our stories focused in on paying down our technical debt. If we didn’t, the debt would never get down to a low enough point to where we are very comfortable.

What is cool is that it really shows what the team wants to focus on next. People can have others vote up their ideas, etc. Also, getting the votes back at the completion of an idea is key. As you can imagine, our forum is private. The one cool thing about UserVoice is you can create multiple forums, with different ranges of settings, so you could also have a public forum, or a different private forum for a select group of users, etc.

One thing I wish I could do is maybe give different # of votes to different users. Integration out of the box with TFS or other systems would be nice too, I haven’t looked to much into that though.

If you have a team that ranges from medium to large, I would suggest checking out UserVoice to get the ideas and opinions of the members out on the table regarding your technical debt. You may be surprised as to what gets voted to the top!