Estimate Support Work

Many teams provide support work for the product they’re working on now, or even for other products they worked on in the past. That means they have to manage interruptions. And if they work in iterations, they need to somehow estimate or leave room for support work.

Here’s one way to estimate support work:

• For the next three iterations, measure the amount of support work the team does. Track the cycle time for the support work, regardless of what kind of a board you use.

• At the end of three iterations, see if the cycle time clusters around some average or mean. You might have two different means: the relatively easy support items and the much more difficult items.

• Now, leave room in the iteration for the number and type of support items you see from your history.

You might discover that support takes close to half the time in your iteration. If so, do some root-cause analysis. Does the team need to fix cruft in the code as it proceeds? Does the team need to add tests because it has insufficient tests due to having taken shortcuts?

One question I like to ask is: Do we need to fix this problem now or is it possible to package up several fixes and do them all at one time? Sometimes the answer is yes. If so, gather the problems and spend some team time fixing those areas of the code and tests so the team has more confidence in those areas.