What is the acceptable upper time limit allotted for one development task?

Question

When asked to rate and / or while reading my colleagues, they often read something like this:

• Make a new page ############# with the function ############### - 8 hours
• Create a new control ########## - 21 hours.
• Fix error in module ######## - 15 hours

I think that when the assessment for one task is more than 5 hours, you should strongly consider splitting the task into smaller subtasks.

The problem with ratings, such as 21 hours, is that you risk losing many hours so that management never knows about it before it's too late. In addition, large scores may be a sign that the task is poorly defined. Of course, this cannot be a very strict rule, since its exceptions are easy to understand.

So my questions are:

• Do you have an upper limit for evaluating your task, and if so, where is your limit?
• What is the acceptable level of detail for your task?

Answer 1

When we do our planning, we break things down into 4-hour tasks (in the longest). And we only plan 4 working days a week. (We assume that the rest of the time is occupied by meetings, etc.)

Answer 2

In planning projects, I do not like if any task is shorter than 2 days. Capping for less than one day seems rather restrictive, as it will not take into account any task with a significant detection component.

And we book 6-hour days, assuming the other 2 hours will be busy with meetings and other various tasks.

Answer 3

If you keep track of your score / actual history, you can probably calculate the hours by accuracy and determine exactly which number is right for your team.

Answer 4

When I work, we have a 24-hour limit, which most of all can be obtained by a separate card. If this is more than that, it should be broken into small enough pieces so that you can observe the movement after daily standing, since otherwise one of them would become stuck in the watch and additional resources may be required to unlock it. My personal preference is to try to go no more than 16 hours, when some cards can score points in terms of the time required for the assessment, as new problems were discovered that made the card become a kind of black hole in terms of swallowing a lot of time in a sprint.

Answer 5

as you have already pointed out, tasks that take more time X should probably be broken down into smaller tasks, the smaller the better, since most developers really poorly evaluate, stating that I provided accurate estimates for up to 3 days of work (24 hours ), but your mileage on the team may vary, so definitely choose the smallest one.

Answer 6

I see two points of view: developer ratings and project manager management.

From the point of view of the developer

I do not think that there is a rule to set an upper limit for evaluating a problem. At least I could not configure the application for all the projects that I worked on.

Typically, the rule is to break down the task, which will be evaluated in smaller parts, if the task is too complicated to evaluate as it is, or if the assessment is difficult to justify to the project manager / client / other interested parties without providing other details ( as a project manager, I always ask for details about the evaluation).

Given this, we had tasks lasting 4 hours (but not less than 4 hours), but also tasks lasting 1 week (sometimes 2 weeks, but the assessment was based on historical data).

From the point of view of the project manager

I prefer to manage tasks at a weekly level of duration. The transition to detailed tasks of subtasks is a matter of micromanagement management (usually the team leader / technical processor has control over it) and transforms the tracking of the progress into a big mess with potential false data.