How am I supposed to know how many days something will take? [closed]

Answer 1

Some thoughts about estimation:

• Estimates are different than commitments. They are a best guess using available information about effort (not time) that a body of work may take.
• Estimates are not a single number - you should really think of estimate as either a range (lower/upper bound) or a value and a confidence factor.
• Estimates have a margin of error - to reduce this margin you generally need to spend more time performing analysis and evaluation. There is a point at which the effort to produce an extremely accurate estimate will begin to approach the effort of the task itself.
• Producing a reliable estimate based on vaguely defined body of work is extremely challenging. High margins of error should be expected in such circumstances.
• When estimating a task, the best guidepost is experience with similar tasks in the past.
• If historic information isn't available (either because the work effort is unique or you don't track this history) - the best you can do is decompose the task into the finest level of work that makes sense.
• Try to ask other people in your organization who may have experience with the system or codebase to review your estimates.

Answer 2

Thank you for all your answers and feedback.

It's been a while since I asked this question, and since then I have greatly improved my time estimation skills using scrum and agile methodologies. We use whiteboarding and scrums, and we delivery in chunks, on time.

As for when the entire project will be delivered, depending on the size of the project, the delivery date is still unknown. However, by breaking up tasks into stories and sub-tasks, we can get an idea of project's magnitude. This enables us to show management whether their delivery expectations are realistic.

Furthermore, having a backlog of tasks allows us to continually re-prioritize with each sprint. This ensures the highest priority issues are completed. Eventually, the remaining items in the backlog are insignificant, and the product is "good enough" for release.

So far it has worked well.

More details: http://www.scrumalliance.org/pages/what_is_scrum, http://www.goodagile.com/scrumprimer/.

Sorry to mark my own response as the answer, but this is what worked for me.

Answer 3

The best advice I can give is to break down a task into smaller pieces then estimate those. Maybe attach a "confidence" percent to each sub-task to calculate an optimistic and pessimistic range. That way when your boss says "5-8 days? That doesn't help me at all, where are you coming up with these numbers!?!?" you just show him your breakdown and you have justification. A competent manager should put your butt on the line for what you commit to, not what you digress to be bullied into committing to.

Answer 4

Better estimates come from experience.

You could also employ the Function Point Analysis method to get a good starting point. Then, give your project manager regular updates. Thus, on Friday when the project needs to slip into next week, your project manager won't be surprised.

Answer 5

If you can, find another job. Your boss seems to have no idea about project management, resource management and software development.

In general, all you can give is estimates. Your estimates will get better with experience (for the most part, you'll estimate far more effort than you do today). And - as any sw developer knows, there's always an option of hitting some stupid issue which will take 90% or even more of actual effort (and hugely increase development time).

Answer 6

I generally say it will take 3-4 times longer than what I really think. For instance, if I know I can build something in two days, I'll say a week or so.

That way if you finish well below your guesstimated time, you will look like a hero! :P