Our approach is to sort and maintain those lists independently, then create a single aggregated list during a release planning session. As such, there is no dedicated percentage of development time to each list. Subsquent iteration planning meetings are held to review the merge decisions that were made up front during release planning, just to ensure any new information that comes up can be put to use.

This merging of the lists does add a little bit of time to the planning process, but it is time well spent. The aggregation process forces our different stakeholders to periodically meet to discuss the issues, determine what is most important for the product at the time, and to coordinate the execution of the plan. Since those stakeholders have to be present to perform these sorting tasks, visibility into the process gets a huge boost.

As for the interests rates, I think you’re right to consider how much the “hack” affects future development efforts. The LDAP example is a great one.

Thanks for the feedback!
Patrick

You mentioned three different lists (refactoring / new functionality / bug fixing) with different owners. How are you managing those? Are you dedicating x% of dev resources to each one in a given release (where prioritization is separate for each list)? Or are you prioritizing the aggregate list of all items?

I think either approach is workable. A single prioritized list would help the team stay focused on the most important stuff. Three lists, with dedicated capacity to each would help a team maintain a particular strategy or vision.

Please tell us which approach your team is using.

As to interest rates – I think Mishkin is right – we don’t have a reasonable way to know. “Bad code chunk X” will have an unknown long term impact. We have some short term visibility, but we don’t really know. Here’s an example:

User authentication is “hacked together” and the product is launched. It works great for new user signup and login. What is the interest rate?

If all scheduled dev work surrounds other functionality that doesn’t touch the authentication functionality, then the interest rate is low.

If the plan is to move to LDAP (external) user authentication, the interest rate would be high. Background – LDAP is a feature that would allow users to not have to log in (if they are already logged in to their network) to be authenticated. These changes would be likely to touch the previously “badly written” code.

Its important that someone owns the list of debts, though. Otherwise, they are quickly forgotten.

I wonder what an interest rate scheme would look like on tech debt? Anything that helps put these things in terms management can understand ends up being helpful :)