What estimation method do you use? [closed]

Question

In our organization, we mainly use Use Case estimation for new use cases which is very clear and simple. However we sometimes deal with tasks that are not related to Use Cases or are UI related or sometimes we deal with maintenance tasks in legacy application that we do not have written Use Cases of. So we developed an in-house method using complexity points for these tasks. It simply categorizes tasks into scale from very simple to very complex according to a guideline and give every scale a size. We calculated a conversion coefficient to convert between UCP (use Case Points) and CP (complexity points) in case the project used both methods. In our organization the PM usually have technical background to do the estimation. S/he may consult the team if needed.

I want to know more about other people experience.

What size estimation method(s) do you use/recommend (Use Case Point, Function Point, Class Point, ...) ? Or do you estimate effort directly? Who does the estimation in your project (PM, Team, Estimation committee like in Delphi method, ...)?

Most importantly please tell us about a situation where your method failed and why do you think this happened.

Answer 1

Sometimes you just don't know how long is it going to take, or don't know in some part. Sometimes you think you know and your devs have other knowledge different than the one you have (sometimes more, sometimes less).

The best estimate you get by analyzing first you as a PM and without giving the team information about your numbers, ask for a meeting with the team to tell you their estimates.

If you and them differ a lot from what you thought it would take, resolve your doubts asking how they came to those values​​. And try to establish a reasonable point given that either you or them may have forgotten something.

From the Devs, you require them to tell you their time estimates considering also what they have as an unexplored territory. (Thing that sometimes devs tend to obviate)

That's why I've created my own Developer's Rules of thumb. These estimates are not imperative, but are a good idea to start managing estimates, perform estimations, and assembly tasks in the medium and long-term project. These are my rules of thumb:

• If the task is part of known duration and estimated duration (ie, parts that are known as going to take, and parts where the team is almost guessing) the estimate should be estimated as if it were 2 different subtasks (This does not mean create a new task, but estimating them separately and add up the estimates.)
• If the subtask is guessed duration (unknown), estimate with a mattress that is 50% to 100%.
• If the subtask guessed is less than half an hour, triple the estimate (ie, 10min -> 30min).
• If the subtask guessed is less than 6 hours, 50% estimate mattress (ie, 2h -> 3h).
• If the subtask guessed is less than 2 days, estimate 30%-35% of the mattress (ie, 3d -> 4d). Otherwise 20% of mattress.
• If the task has over three days of work, break it up into 2 tasks.

Those may sound a little excessive, but I assure you they are not.

I don't know if in English you call it mattress to the "extra time", English is not my native lang. Sorry for that.

I do not remember, that this estimation method failed by far. Once it happened that one of the developers was a junior and came to a point where not only made ​​a mess in the code (complicating the next guy who would have a task) but also could not solve a certain task, which delayed the delivery, since in what was working was one the main items.

Answer 2

Since the question is broad there is a broad answer. Start with Steve McConnell's "Software Estimation: Demystifying the Black Art". Once you get some "academic" background in estimating read more about COCOMO and COSMIC.