What is the acceptable upper limit of time allocated to a single development task?

Question

When asked to estimate and/or while reading my coworkers estimates they often read something like this:

1. Make new ############# page with feature ############## - 8 hours
2. Create new ########## control - 21 hours
3. Solve bug in ######## module - 15 hours

I think that when the estimate for a single task is more than 5 hours you should strongly consider dividing the task up into smaller sub-tasks.

The problem with estimates like 21 hours is that you risk losing a lot of hours without management ever knowing about it until it's too late. Also, large estimates can be an indication that the task is poorly defined. Of course this can't be a very strict rule since it is easy to conceive exceptions to it.

So my questions are:

1. Do you have an upper limit for your task estimates, and if yes where is your limit?
2. What is an acceptable level of detail for a task in your opinion?

Answer 1

When we do our planning, we break things up into 4 hour tasks (at the longest). And, we only plan for 4 work days per week. (We figure that the rest of the time is taken up with meetings, etc.)

Answer 2

Where I work we have a limit of 24 hours being the most that an individual card can get. If it is more than that, it should be broken down into small enough chunks that one can see the movement after the daily stand-up, as otherwise one is kind of stuck in terms of hours and may need additional resources to unblock. My personal preference is to try to go no higher than 16 hours where some cards may balloon in terms of hours needed from the estimate as new issues were discovered that caused a card to become a kind of black hole in terms of swallowing lots of time in the sprint.

Answer 3

as you already point out, tasks that take longer than X should probably be broken out into smaller tasks, the smaller the better since most developers are really bad at estimates, having said that I have provided accurate estimates up to 3 days of work (24 hours), but your team mileage may vary, so definitely go for the smallest you can

Answer 4

If you track your estimate/actual history, you can probably plot hours by accuracy and figure out exactly what number is appropriate for your team.

Answer 5

In planning projects I do not like having any task shorter than 2 days. Capping it at any less than a day seems pretty restrictive, as that won't account for any task with a significant discovery component.

And we book 6 hour days, assuming the other 2 hours will get taken up with meetings and other miscellaneous tasks.

Answer 6

I see two points of view: developer's estimations and project manager's controling.

From developer's point of view

I don't think there is a rule on setting the upper limit for a task estimation. At least I couldn't set one to apply to all the projects I worked in.

Normally, the rule is to break the task to be estimated in smaller pieces if the task is too complex to be estimated as it is, or in the case the estimation will be hard to be justified to the project manager/customer/other stakeholder without providing other details (as a project manager I always ask details about an estimation).

Considering these, we had tasks of 4 hours duration (but never less than 4 hours), but also tasks of 1 week duration (sometimes 2 weeks, but the estimation was based on historical data).

From project manager's point of view

I prefer to manage the tasks at weeks level of duration. Going to detailed subtasks tasks is a matter of micromanagement (usually the team/tech leader has control there) and transforms progress tracking in a big mess, with potential false data.