Where Does the Time Go?

As a development manager, I’d like the people working with me to be as productive as possible. If I understand how much time the team is spending in different areas, then I’ll have a better understanding of how we can improve. I need a way to track how much time we are spending in the following areas:

• New product development
• Defects
• Administrative tasks

Have you heard this line of reasoning before? Have you taken it yourself? Many of our new customers struggle with how to get this data. They basically have three options: track effort, estimate all defects, or ask your team. I’d like to focus on just defects in order to discuss the strengths and benefits of each option. 

Option 1: Track Effort

Pros: Highly detailed time tracking.
Cons: Time consuming. Inaccurate data can be misleading.
Verdict: This may be the best option for consulting companies who bill time, but otherwise it is overkill.

Although tracking effort can provide very detailed data, tracking effort on tasks can be wasteful because it doesn’t help software get built any quicker. Besides spending a good amount of time, it may also be an activity that provides little perceived value to the team, so they may have little incentive to record time accurately.

Option 2: Estimate all of your defects

Pros: Defects and Stories are treated the same.
Cons: Defects shouldn’t have points because they are negative features.
Verdict: Don’t estimate defects. They should always have a zero if you are measuring velocity. 

Estimating all defects may be a less time consuming option, but this approach has other issues. It doesn’t really make sense to stop the team in the midst of the current iteration and estimate a defect causing a critical production issue. I suppose the defect could be estimated after the work has been completed, but that smells wrong. Also, most defects are very small. Determining which ones are small and which ones will take more effort usually takes some investigation. Does it make sense to start the investigation and then estimate the defect? In many cases, the developer will have spent enough time in the investigation to know the exact changes required. Does it make sense to assign a standard number of story points, such as one-third or one-half, to each defect? Probably not. At that point, you can just count the number of defects. 

Another point worth considering is that defects are negative features and shouldn’t be counted towards velocity. Velocity should be reserved for story points so it represents progress forward not amount of work completed.

Option 3: Ask your team

Pros: Very little setup required. Provides solutions to the problem instead of just data that may show a problem exists.
Cons: No quantitative data.
Verdict: Your team knows what is getting in the way.  Ask them.

Let’s go back to the original goal of the development manager: “I’d like the people working with me to be as productive as possible.” Everyone should agree that knowing how much time is being spent in each area could provide some evidence that a problem exists, but this knowledge definitely doesn’t help solve the problem. Knowing that your development team is spending too much time on defects is much less important than understanding why they are spending too much time on defects.

If you are holding retrospectives, then getting this type of knowledge should be easy to attain. Ask the team to focus a retrospective on the following, “What could we change in order to catch more defects during the development process?” A properly structured retrospective on this topic will provide several actionable ideas in an hour or two.