Follow me on Twitter Twitter_16
Subscribe to my RSS feed Rss_16
Posted over 7 years ago

Agile, Focus Factor, and Time Tracking

What is the ROI on time tracking in Agile?

From an engineers perspective

Time tracking sucks. It prolongs meetings, it forces an engineer to spend time sizing work instead of actually doing work, and it is a value that the engineer is held accountable to (even if it’s only self-imposed).

From a manager’s perspective

It validates your original estimates and gives quantifiable measurability to something that was “undefined” previously. In the end, the most valuable resource I have to manage is engineer time and I would not be able to do my job without the metrics that measure what I’m trying to manage.

Hypothesis

I propose that nearly the same value can be gleaned at lower cost from tracking velocity.

Definitions

Velocity is a measure of how much work a team can accomplish in a given amount of time (a sprint).

Focus Factor is a measure of how much time engineers are spending doing actual work versus other responsibilities (like meetings, administrative tasks, etc.). It requires engineers to assigne ‘ideal work hours’ to each task in a sprint.

If you’re unfamiliar with focus factor, there’s a decent definition of it here.

Theory

One of a manager’s goals is to enable their employees to be as productive as possible. If velocity drops, a manager wants to know why. By dividing ideal work time by available person hours, Focus factor can identify if it’s because the team is doing too much work outside of the sprint goals.

However, I contend that the same information can be obtained by a simple conversation with your engineers (Trust me, your employees will let you know if there is something getting in the way of their productivity).

Practice

Time tracking comes at a substantial cost. Anyone who has spent any time doing agile is familiar with the tediousness of story sizing. By adding time tracking (necissary for calculating focus factor) the time needed for sizing increases exponentially. For every story that the team had to size before, there are some number of additional tasks to size as well. When considering that these sizings are generally done in a meeting, the organization incur the cost of lost resources of an entire team for the amount of time it takes to size all of those tasks (see note 1).

Time tracking can be very dangerous to morale as well. On a mature Agile team, not so much, but on a team that is still building trust time tracking can lead to a sense of accountability (wether internally or externally induced) that can cause engineers to be defensive. Yes, it will point out engineers that are consistently under-performing (but does a team really need a metric to tell them that anyway). An argument could be made that story points could generate the level of accountability as well. However, story points are shared by a team, and are only accounted for at the end of the sprint. For these reasons they encourage a team mentality. Tasks and task-times are tracked to the individual working that task. For these, an individual is held accountable. This does not encourage a team mentality.

Conclusion

Considering the cost’s, doesn’t velocity provide the same (or close to the same) value?

Notes

1: I have also tried a method of task sizing where each team member was assigned a story to ‘task out’ and size prior to a review meeting. The goal of the review meeting was then focused on discussing the tasks, their sizings, and making sure nothing was overlooked. However, I soon found that this method didn’t work very well either. As much as I tried to facilitate discussion I found that when people were expected to just review other peoples work instead of actually creating and sizing the tasks cooperatively, they tended to zone out. The meeting ‘droned on’ and very little was contributed.

comments powered by Disqus