One practical approach is to invert the task list and time box the work. We do this with a “hanging PERT” tool. Define the deliverables for the iteration. Anchor the iteration deliverable day. Assemble the tasks needed to get to the deliverables in reverse order. This is hard to see in words, but imagine a milestone that says (and milestones are always nouns, tasks always verbs – the you can read the schedule as a statement of work) iteration completed. What pre-conditions are needed to make that noun be “true?”

Logic would tell you that the pre-conditions them selves have to be whole – that is fully functional entities that can then be assembled into a deliverable. Keep working backwards in the iteration until the start date of the cycle. That’s all the work you can do.

Resource loading is this simple. No one is waiting for a pre-condition.

NOW the problem is that individual people may run out of work for that iteration (assuming they have single specialties) and therefore need to multitask either in support of another parallel cycle or make work ready for the next cycle.

In the end though serializing work through the avoidance of multitasking – at least in software development – is a very bad idea.