Software engineering schedule trick #1

This is part 1 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.

Software engineers go to meetings. They deal with paperwork. They interview candidates. They train new engineers. They prepare presentations and demos. They attend presentations and demos. They go to conferences. They speak at conferences. They deal with suppliers. They deal with customers. They deal with users. They take time off. They lose time to broken builds. They shuttle code changes between codelines. They set up their workstations and other tools. They do maintenance work on older code versions.

All those tasks are normal tasks for software engineers. They need to be taken into account when making a schedule. However, they're not part of any work estimate.

My scheduling trick is to consider that engineers only have about 50% of their time available for work that can be scheduled. The other half goes to the overhead mentioned above. If a one-person task is estimated to take 20 man-days, there's a good chance that it'll take about 2 months to complete under a regular workload.

The 50% number is only an estimate. It's probably between 40% and 60% in most cases. In extreme cases it could be even lower or higher. However, there's definitely no way a software engineer can consistently produce one man-day of work every day without working some significant and eventually unsustainable overtime.

See also part 2 about building schedules by breaking tasks down into small sub-tasks.

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