0

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.

closed as off topic by yegor256 May 15 '11 at 15:16

Questions on Project Management Stack Exchange are expected to relate to project management within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Hello. I believe this question may be closed as being off-topic as it doesn't meet the guidelines from the FAQ Section Listing What Questions Not To Ask Here: your answer is provided along with the question, and you expect more answers: “I use ______ for ______, what do you use?”. If possible, can you please try to remove the answer from the question so we can possibly avoid closing it. Also, it's okay to answer your own question, but you should click "Answer" and add it as an actual answer. Thank you for participating on our site! :) – jmort253 May 15 '11 at 5:07
2

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.

  • I think you mean by mattress a buffer :). I understand from your answer that you do not estimate size. You estimate effort directly. How do you then measure productivity? Is your organization CMMi certified? – M.Sameer May 12 '11 at 19:39
  • In my previous work they were certified. My current organization is not IT centered as the company where I work now is a steel forge, so although the company is huge, certification isn't a priority (because of ROI) since all software products are internal. The previous company was a software factory. I'm not sure whether they were CMMI or ISO. If you're asking about productivity, I don't know if individual level or project level. But if I'm not mistaken, both were collected through reports withdrawn from JIRA (tracker project) and it was related to a "subversion"(Revision control). – apacay May 13 '11 at 14:21
  • I meant the team productivity. It's calculated by dividing the total size of the project by the total actual effort. I will check out JIRA to know more about how they calculate it. Thank you very much for your answer. – M.Sameer May 13 '11 at 16:01
-1

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.

  • I am trying to know what is the preferred method to estimate project size. The expected answer would be something like FP or UCP and reasons behind these choices. What "academic" background you were thinking of when you wrote your answer ? – M.Sameer May 12 '11 at 19:43
  • First, I didn't mean any offense by "academic background". What I meant is that estimating of software size is a science, with a lot of fundamental knowledge, staying very close to probability theory. Before making a decision of what is wrong and what is right in this area one should understand the basics. If interested, I can add more links to my answer to explain further. – yegor256 May 13 '11 at 2:55
  • Thank you very much @yegor256 for giving help. I have read about estimation techniques in papers and books by Capers Jones and Barry Boehm and others. The reason I am asking this question is that some companies do not use formal methods for estimation. They estimate durations or effort not size. Others use methods and roles of thumb they developed in-house. I wanted to know why many people are not using FP or UCP. I also have an impression that UCP usage is wider than FP. I want to know why is that. Do you agree that scientific formal methods are not widely used ? Do you use any ? Why ? – M.Sameer May 13 '11 at 16:23

Not the answer you're looking for? Browse other questions tagged or ask your own question.