Glen Alleman in his post How Long Should Tasks Be gets to the heart of an important issue. When planning, how long can you wait before you know that you are late.
In principle, it works like this – you don’t know you are late until you fail to complete a task on schedule. How late you are depends on the remaining work in the late task. How long can you wait to determine that a task is behind schedule? That depends on where you are on the project timeline and how much “margin” is remaining in the plan.
In practice there are other dependencies. Measurement frequency is important. The more frequently you measure progress against the plan, the smaller tasks increments you will naturally prefer. You want to see progress at every measurement cycle.
Ray Stratton in the newsletter that Glen referenced in his post talked about the problems that occur when you have an “un-natural” work breakdown – to support arbitrary task size limits. He talked about philosophical differences between the doer and the measurer.
I wholeheartedly agree with this sentiment, but state it differently. It is possible that arbitrary task size preferences will require you to divide a task that “appears” atomic to the person responsible for the task. However, in the software development domain, larger atomic tasks, may equally well be evidence of poorly thought out designs, or incorrect assumptions on the part of the developers or even incorrect understanding of the relation of the task to the larger deliverable. Software development tasks proceed from the design activity, individuals “lose the plot”, and developers learn about the problem, while they are completing tasks on the plan.
As a lead developer and a project manager I have used the work breakdown and estimation process guidelines to ensure that our plan and our design are both reasonable:
1) When a task estimate is larger than the guideline calls for, assail the estimate – make the estimator explain what activities are necessary in the task.
2 ) If the task contains a certain amount of “unknown work” – make a separate task for understanding/resolving the unknown work required. Sometimes dividing the task into iterations (draft, working, complete) will help resources bake out the unknowns.
3) If the task can be divided among resources, then its breakdown is not complete – as each resource should have a clear boundary and deliverable. If a large task cannot be easily divided, it may evidence a design that inhibits collaboration, or sharing the work among resources, perhaps a “too tightly coupled” aspect of the design concept.
4) If the task encompasses activities that are “peripheral” or “tangential” (e.g. documentation, knowledge sharing or acquisition) to the relationship of the task to the larger deliverable those also can be separated.
Sometimes what feels un-natural to the doer, is really the evidence of something else going on either in the plan or in the understanding of the work.
BTW – my current team’s max task guideline is 12 hours. The team measures progress in weekly iterations, and our goal is for every team member to have at least 24 hours of tasks (by estimate) completed per week. That task size provides a reasonable opportunity for the team to adjust and correct We assume that the remaining 16 hours of activity is spent in collaboration and administration. It is very rare, that we relent and allow a developer to commit (start) a task that is larger than 12 hours of estimated effort.