Being tech lead on projects means that I frequently am asked to break feature or change requests down into development tasks. I also frequently get asked by other leads how to break work down. Explaining the goals is easy, but explaining the process is a bit more difficult.

First, the main goal is to get the work consistently sized. It makes metrics more meaningful. Two day tasks has seemed about right in the past… it keeps the metrics flowing, but it shouldn’t introduce too much overhead. It’s also nice to have bite-sized pieces so that it’s easier to stay focused and to say when the task is done. It’s also nice to have the tasks break on client-visible functional boundaries so that a release could happen between any two tasks. And, smaller tasks are almost always easier to code review. So I shoot for small-ish, consistently-sized development tasks.

So, how to explain my elite ninja work-breaking-down skills to others? When I size them by whether they “feel” like they’re the right size, I obviously don’t have something tangible to pass on.

A little while back, I read about using BDD-style stories as a mechanism for describing the functionality, which should then be pretty easy to analyze to see if it’s the right size. Still, it’s pretty much a “does it feel right?” approach.

So today, I was thinking that another way to objectify the goal, and possibly make it easier to learn to break down work, is that development tasks should result in no more than 5 significant methods and changes to no more than 4-8 files. Those numbers probably aren’t quite right, but they should be ballpark. This rule of thumb is derived from one of the benefits of small amounts of work, so it’s pretty indirect. Maybe this will be a helpful way of describing work breakdowns to other leads?

Advertisements