I am passionate about managing software debt. You may have noticed from the articles and blog entries I have written and presentation slides on the subject. Over the past couple years teams that I work with use an exercise to identify software debt in their software. Here are the basic steps:

1. Draw a model of your architecture or major application components on a whiteboard.
2. Write down areas of software debt within and between across the model on post-its and stick them close to their respective area. Add the category of software debt that they represent to the post-it (technical, quality, configuration management, design, or platform experience)
3. If any item seems to cross types of software debt try breaking it down into smaller parts
4. Identify the potential value to the software’s users, the business, or the team’s capability to deliver faster or more confidently once it has been addressed sufficiently. You may also find that there are opportunities to break them down into smaller parts here with a smaller win having greater impact.
5. Vote on which of the areas of software debt are most menacing and impact the most near-term development.
6. Prioritize the areas of software debt in stack rank order so that they can be discussed with the customer or Scrum Product Owner (if they are not already in the room, which I do recommend)

This exercise is simple and provides the business opportunities to improve their software for continued delivery of value. Please let me know if you use this exercise and how it works out. An example of this exercise is below.

Be Sociable, Share!

•