Splitting Huge Tasks

On occasions I deal with an issue small enough that it barely deserves a full-blown blog post, yet it is hard to pack it into 140 characters of a tweet. However, when I’m advising on such an issue for yet another time it is a clear signal that sharing an idea how to deal with it might be useful. So, following an experimentation mindset, I’m going to try short posts addressing this kind of issues and see how they are received.

One of pretty common problems is with splitting tasks. For example a typical task for a team can take something between 4 hours and a couple of days. And then, there is this gargantuan task that takes 3 months. Actually, 3 months, 5 days and 3 hours. It is, however, quite a coherent work item. Basing on merits it does make sense to treat it as a single task.

On a side note: for whatever reasons it happens more often in non-software development teams.

The problem is, it heavily affects any metrics you may gather. Sometimes it affects metrics to the point when analyzing them doesn’t make much sense anymore. If you include this huge task in your metrics they all go mad. If you don’t, you basically hide the fact that a part of the team was working on something that isn’t accounted at all. So the question is: should you accept it and move on or do something with the task?

I’m not orthodox but I’d rather split the task to smaller ones. Usually this is the point when new issues raise – for example the task can be split but for pieces so small that measuring them separately adds way too much hassle. An alternative can be grouping these tiny pieces into batches of a size that does make sense for the team.

Anyway, I’d still go with splitting the task, even if division is artificial to some point. The knowledge you gain from metrics is worth the effort.

In short: when in doubt – split.