Question on Software Estimation.

[Mohan Karthick]

Hi

Can anybody advice how to do Project Estimation in a role of Project Leader, as i came across with this question many times but not able to satisfy the interviewer.

Thanks,

[Scott Ambler]

You might find http://www.ambysoft.com/essays/agileProjectPlanning.html to be of interest.

- Scott

[Ilja Preuss]

Originally posted by Mohan Karthick:
Can anybody advice how to do Project Estimation in a role of Project Leader

Ideally, you let the people who later have to do the work estimate how long it will take them, and possibly adjust that by historical data on how estimates of those persons typically differ from actuals.

One way to do that is to use the Extreme Programming Planning Game.

[Robert Paris]

Ideally, you let the people who later have to do the work estimate how long it will take them, and possibly adjust that by historical data on how estimates of those persons typically differ from actuals.

I agree with that. Everytime an estimate was done by someone who was not going to be doing the task, they were way off. I find that in addition to this, though, you need to know the people well and know whether they can normally judge how long a task will take them. So I normally:
1. Talk to the person about their estimate
2. Keep an idea from proj. to project of whether they tend to under/over estimate

Now, if you're estimating for a project that you'll have to hire people for (or that you'll later assign to people), perhaps you should use a combo of your own experience with the Use Case Point Method. http://www.coderanch.com/t/153403/java-Architect-SCEA/certification/meaning-Points

[Henry Wong]

I always considered this skill to be a form of "black magic"... :-)

I have seen both extremes, although more projects tend to be under-estimated than over-estimated. I have also noticed that there is little relation between technical skill and accuracy.

Too bad we can't just do the project first, then estimate the time for it... :-)

Henry

[Ilja Preuss]

Originally posted by Robert Paris:
2. Keep an idea from proj. to project of whether they tend to under/over estimate

Full agreement - that's what I tried to say with "adjust by historical data"...

[Ilja Preuss]

Originally posted by Henry Wong:
Too bad we can't just do the project first, then estimate the time for it... :-)

But you can get close: Split a project into many small projects (for example one week iterations) which implement a small part of the functionality end-to-end. That way you can rather easily gather data on how fast you really can go.

[Stan James]

We spent a rough day with a couple IBM guys who wanted us to break down every task into how many hours of work were required for front-end, mid-tier, back-tier, database, who would do the work, what were their skills, etc. We eventually wore them down to accept the way we estimate tasks as 1-to-8 story points and add them up. I have heard of teams who figure once they get the story granularity down to a few days worth of work the sizes will all average out and they can do adequate estimates just based on the story count.

The industry as a whole is very poor at estimating. That's led us to trust our instincts and not invest too much effort in it. Don't confuse precision with accuracy. "The project will be done on November 11th" is precise, but no more accurate than "The project will be done in the third quarter". If the dates are nailed down, substitute some other unknown, eg how many features you'll get done.

[James Coplien]

In the Organizational Patterns book you can find a small pattern language on scheduling. Almost all of it comes from Ward Cunningham's EPISODEs pattern language, and we have seen it empirically validated again and again.

To me, the main points are these:

• In the four-legged stool of schedule, staff, functionality and quality, schedule is sacred. Change anything else, but not schedule. There is a lot of research that says that there's no better way to piss off a customer than to slip schedule. The best thing to do is to renogiate functionality. It happens all the time, even though the marketing superstructure may not be willing to acknowledge it. In a large telecom company where I used to work, we found that during maintenance, about 40% of the contracted features changed and were re-negotiated at the engineering and developer level after the contract was signed because conflicting requirements, incompatibilities, and nonlinear staffing repercussions arose in implementation.
• Directly relevant experience, or analogous experience, are the best indicators. Just about anything else involves the moral equivalent of reading goat entrails and stars in the heavens.
• Even if you can predict well, you still can't win. A management simulation study done at MIT shows that developers sense an overambitious schedule and panic to the degree they overshoot the schedule, and that they sense a padded schedule and defer work until it is too late. In both instances you overshoot the schedule by about the same amount. The solution seems to be to keep two sets of books: one for the market, and the other for your developers. In a Community of Trust you can show both sets of books to your developers -- and in those rare communities of very high trust you can show both sets of books to your customers, too.
• At the Object conference I chaired a few years ago out here in Boston we had a panel where the panelists were asked, "What is the sure sign of a sick project?" I think it was Tom DeMarco who answered: "A schedule worked backwards from a delivery date." Such a linear schedule is not agile.


Contrary to previous postings:


• You can't accurately plan anything in detail without tanking productivity. Let the Developers Control Process; they know how to interleave detailed tasks if you give them a priority-ordered Work Queue.
• Take a modest bow to requirements but be prepared not to take them too seriously. You won't know most of them until you try to implement. This reflects not only the hard experience gained on real projects, but some fundamental properties of the design process itself. A good read is the book by Reiser et al. entitled "Software Development as Reality Construction." After reading it you'll let go of any delusions you had that you can usefully predict requirements before you're done implementing. Instead, Engage Customers. See <em>Contextual Design</em> by Beyer and Holtzblatt -- what a great book.



Cheers,

Cope
[ May 03, 2005: Message edited by: James Coplien ]

[Eusebio Floriano]

How can we estimate the productivity in an very heterogenic team ?
Some senior developers, some junior, and so on.


Regards,

[Ilja Preuss]

Originally posted by Vinicius Boson:
How can we estimate the productivity in an very heterogenic team ?
Some senior developers, some junior, and so on.

The same as with every other team - start with gut feel, preferably with input from the whole team, and then measure.

The performance of a team is far from simply being the sum of the performance of its members. It will most heavily depend on how well the team will work together - will they communicate and collaborate well, will seniors be effective at mentoring juniors etc.

[James Coplien]

1. Ilja is exactly right -- you need "good guts."

2. You are much better off with heterogeneity than homogeneity. Homogeneous teams too often deadlock or go into brownian motion. Heterogeneity fuels the engine that keeps you from getting stuck.

[Ilja Preuss]

Originally posted by James Coplien:
2. You are much better off with heterogeneity than homogeneity. Homogeneous teams too often deadlock or go into brownian motion. Heterogeneity fuels the engine that keeps you from getting stuck.

Good point - in a well working team, diversity of experience and opinion will foster creativity, which can be a major contribution to success.

[Pieter Schmidt]

Originally posted by Mohan Karthick:
Hi

Can anybody advice how to do Project Estimation in a role of Project Leader, as i came across with this question many times but not able to satisfy the interviewer.

Thanks,

Estimation comes down to 2 different methodologies; parametric or expert based techniques.

Parametric methods involve using tools that rely on historical data calculate an estimation based upon functionality, e.g. COCOMO, Use Case Point/Function Point analysis...
Expert techniques rely on building an estimate based upon the collective experience of 'seasoned' practitioners - developers...

Have a look at these articles on the two different methods for estimation

http://liemur.co.uk/Articles/UseCasePointEstimation.html

http://liemur.co.uk/Articles/Wideband_Delphi.html