Software engineering schedule trick #2

This is part 2 of a series of about 5.

Creating schedules for software engineering is hard. Some consider it a black art. I've learned a few tricks that make the process a bit more precise. Here's one such trick.

In software engineering, the devil is in the details. Tasks that look simple at the high level usually reveal some unexpected complexity when investigated in detail.

That's why it's impossible to accurately schedule any task from just a high level view. The only way to schedule a task is to break it down into small tasks, each small enough that it can fit in a person's brain.

Also, since every engineer is different, each individual task must be estimated by the engineer who'll actually do the work. Estimating each individual task is really part of the design work.

Another important trick is that estimating tasks can't be done alone, it's best done in pairs. By having to explain things to another person, the person doing the estimates needs to slow down enough that they'll be able to actually consider the relevant details.

My rule of thumb is that tasks need to be broken down into chunks between half a day and 2 days, by granularity of half a day. Tasks larger than 2 days are too complex to be estimated properly. Tasks can't take less than half a day, because of the time it takes to compile code, install it, run the tests, and get the code peer-reviewed.

See also part 1 about estimating how much of an engineer's time can actually be scheduled.

See also part 3 about scheduling the debugging phases.

See also part 3.5 about prioritizing bugs.

See also part 4 about scheduling in teams.

See also part 5 about schedule overruns.

See also part 6 which concludes the series.

Copyright 2012 Jean-Baptiste Queru / CC BY 3.0
Shared publiclyView activity