How to estimate the length of unforeseen tasks? [closed]

Closed. This question is opinion-based.开发者_运维问答 It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

i would to know if somebody knows a methodology or whatever that be capable of estimate the length of unforeseen tasks.

Many times i have to leave some task and attend many others, i have read about the context switching, but my problem is that i can't, becouse i don't know, how to estimate the lenght of unforeseen task. It's possible ?

---

The key is historical data.

If you record how long (including interruptions) it takes to complete a given type or size of task, than for future tasks, you just need to identify the type/size of a new task, and apply the historical data to figure out how long such a task typically takes. Since the data you've been recording included various interruptions, etc., then the estimate for the future will factor those in as well.

Example: lets say this is the data for the last 10 times you had to make a textual update to a web page:

time     note
10m
10m
1.5h     got pulled away to fix a production bug
10m
45m      server offline due to upgrade
10m
10m
4h       entire staff evacuated due to bomb scare
10m
10m

Clearly, it only takes you 10 minutes to do the actual update. However, the average time it took in real life is about 45 minutes. If you have 5 updates to do tomorrow, estimate them at 45 minutes each.

This approach should also help factor in unforeseen items that are part of the task -- it only takes 10 minutes to do the code, but 15 minutes to deploy it because you have to FTP it over here, then rsync it over there, etc. Again, that will show up in the historical data.

---

I tend to give estimates in hours of work, so that if I am pulled off of a task, then I can point to what I have done, and how much longer.

I tend to use this method though: http://www.joelonsoftware.com/articles/fog0000000245.html

That way supervisors can see how much more work is left, once I get back from the unforeseen task.

---

The Pragmatic Programmers advise choosing your units of measure wisely to give yourself leeway.

So, rather than saying "120 days" say "4 months" (or "half a year").

Also, if you have unknowns, stating this fact to your customers upfront, and keeping them in the loop, can't hurt.

---

Not likely until you realize that a task has been overlooked since you can't know what you're missing by definition.

---

First things first, there is no way that you can estimate the length of every little task in big projects. Categorize your tasks by criticality, and only estimate times for those tasks that are crucial to your project.

The next move would be to allocate free time amidst less critical tasks that are simultaneously going on with the critical tasks. Gantt charts would serve this purpose beautifully.

---

If you have consistently unforeseen tasks then you can est. the about of time you work on those and add as a buffer to determine end date (not work effort for the project since the unforeseen tasks sound as if they are assoc. with other projects). There have been studies that show an avg. programmer is 60% productive on an assigned project, so buffering 30%-40% might seem high (or it might not) but would be a good starting point.