Estimating the impact of technical debt on stories – heat maps

I have been in several conversations recently about how we take refactoring and technical debt into account when estimating work on IT projects.

For those not up with the jargon – refactoring involves improving or simplifying your code without changing the functionality.  This means that the code can run faster and more reliably, be better maintained etc.

Technical debt is the concept that if I take short cuts to get a project into production then I am borrowing from the future – in other words someone in the future will need to do more work to make up for the fact I am doing less now. 

Unfortunately though, even if I do all the work that needs to be done now, the system I build will become less fit for purpose over time if it is not constantly maintained and refactored which means that all systems have some level of technical debt in them.

In fact when you talk to some teams they will go to a lot of trouble to avoid making changes to particular systems or system components because they are “delicate” or more accurately unstable and scary to work with.

One of my favourite tools for taking this into account when I am estimating the cost of adding or changing features in a system is the a “heat map”.

Essentially a heat map is a map that shows where to expect trouble in a system and where to expect smooth sailing.

To create a heat map, simply take any model of the system and shade or colour different areas of the model to indicate the ease or complexity of working on different each area. Things that can be taken into account include whether there are automated tests in place, areas of spaghetti code, areas that involve complex integration code, areas the developers know well or anything else the team feels is relevant to the complexity (and therefore estimated effort) involved in working on different areas of the system.

The team adjust estimates involving different areas of the system in line with the “heat” of the particular area.

Once the team has created the heat map they use it to update their estimates for changes that involve different components of the system.

I the team are using relative estimating techniques like planning poker they they will simply discuss which areas of the system are impacted by the change and then take this into consideration when voting on their estimates.

If the team are estimating by time, then they might agree, for example, that any work involving the lightly shaded “a bit scary” components will take 20% longer and work involving the “bad lands” will take 200% longer.

This is a simple way to take a lot of complexity into account when doing your estimates without having to go to a great deal of effort.