Estimating time to complete tasks [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 9 years ago.

Improve this question

I know this question has been asked several times on here/programmers and it is quite a common, classic question:

Just how do you accurately give estimates for how long a task will take?

The problem I have is for point-and-click tasks in Windows, I can give accurate estimates. For coding something new (as in using APIs I am not familiar with) I cannot estimate an accurate time to save my life. It's a case of thinking of and saying the first number (of days/weeks/whatever) that comes into my head. For code that uses APIs I am familiar with and apps I can instantly say I can develop (e.g. a notepad-type app) I could give an estimate that is accurate.

Any help appreciated.

Thanks

Answer 1

Focus on the pieces. When you try and estimate a task at a high level, not only is it daunting, but you will fail to accurately factor everything that will comprise the total time.

Instead, do not even try to guess at the total (not only is it not useful, but it can actually bias your estimates of individual tasks), but rather sit down and just try to think of all the sub tasks that comprise the task. If those feel too big, break them down into even smaller sub tasks.

Once you've done this, give each of the sub tasks an estimate. If any of them are larger then about 4 hours, the sub task probably hasn't been broken down enough. Add all of these sub estimates up. This is your estimate.

Using this approach forces you to reason out what is actually required to complete the task and will let you produce better estimates.

Make sure you think of the non obvious steps required to complete a task as well. If you're writing a piece of code, did you include time estimates for writing the associated unit tests? For testing the code? For documenting it?

When converting hours to days, use realistic expectations about how much time you actually spend heads down working. The general consensus is that a developer can complete 4-6 hours of work in any given 8 hour work day. This roughly matches my personal experience.

If you have other team members, you can try a technique called Planning Poker. At its simplest, the idea is to get each member of the team to go off and estimate each of the tasks individually. Once that is done, the team gets together and compares estimates looking for large deviations. This tends to bring to light if the task wasn't clear enough, if there are members of the team who posses relevant information that the others don't, or if there are different assumptions being made by different team members.

When doing your estimations, be aware of your assumptions and document them as part of the estimates. Assuming x, y, & x, task q should take n hours. These could be things like assuming the availability of a QA engineer to test the feature, assuming the availability of a development environment to deploy the feature to for testing, assuming the compatibility of two third party frameworks that haven't been tested together yet, assuming that feature z that the task is dependent on is ready by a certain date... Etc. We make tons of these assumptions all the time without being aware of them. Documenting them forces you to be aware of them and allows other parties to validate that your assumptions are correct. And if the estimates do turn out to be wrong, you have much more information to analyze why.

Even following all of this advice, you will still frequently make inaccurate estimates, but don't feel too bad because our brains are hardwired to produce terrible estimates for abstract tasks. We have a multitude of cognitive biases that affect our ability to gauge task size and effort.

I recommend reading this article for even more information and advice:

http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/

Answer 2

I've mostly worked on projects with "smaller" durations, but something that has worked well for me is to break apart the task into small enough sub-tasks that I think I could implement each one in about a day. For some items, this means just two or three sub-tasks, for others, this might mean dozens or hundreds. Add in some overhead percentage that gets wasted on non-productive activities, some overhead for exploring wrong directions, and hopefully you'll get a number that's within a reasonable range of the end result.

Answer 3

what I usually do is breaking down the tasks to small tasks. the largest task should not exceed 2 days. estimating small tasks is not that difficult. each small task has its test time included in the estimation, so I don't end up with a ton of untested code at the end of project.

Breaking down the task to small pieces only is possible if there is a high level design in place otherwise the estimate is just a rough guess which is usually 2 weeks, which is the famous 2 weeks most developers use;)

adding some time to the end of the project to integrate-stabilize-bug fix makes it a reasonable estimate.

Answer 4

Similar to what sarnold mentions, breaking apart the task is key...but it may be more difficult to get it down to fine grained 1-day increments if you don't understand the domain/technologies involved. In your case, I would suggest the following (especially if this clearly doesn't look to be a task that is going to take less than a few days to complete):

1) Firstly, you need to ask around to your team/colleagues to see if they can shed some light (and/or if they've used the same API/technologies you're using). If nobody knows anything, you're going to have to own up to the fact that you simply don't have enough data to hazard a reasonable guess and will need to spend X days to investigate (the amount of time to investigate needs to be aligned with the complexity of the API/Domain you are working with)

2) At the end of the time you've allocated to investigate the new technology, you should be able to do a very basic hello, world-ish type application that uses the API (compiles, links, and runs fine). By this time, you should be in a good position to determine if your task is going to take days, weeks, or months.

3) The key thing to do next is to, as soon as possible, identify any major roadblocks/hiccups that are going to blow away your predictions...this is key. The absolute worst thing you can do is continually go to your manager/customer on the due date and mention you need a significant amount of additional time to deliver. They need the heads up as soon as possible to help remedy the situation and/or come up with a Plan B.

And that's pretty much it...it's not rocket science but you basically provide an estimate once you're in a position to give one and then make sure that you update that estimate based on new, unanticipated events that have a significant impact on your ability to make anticipated dates.