wood burning stoves*
The moose likes Agile and Other Processes and the fly likes Software Project Estimation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Software Project Estimation" Watch "Software Project Estimation" New topic
Author

Software Project Estimation

Ajit Wadekar
Greenhorn

Joined: Mar 12, 2003
Posts: 20
Hi

I don't know where to put this so I am putting my post here. I want to know more about the Software Estimation Methodologies available.
I am doing it for quite some time now but without any scientific or any formal methodology.
What I use currently in my project is my past experience from the same project or discuss it with my manager and other people, which isn't scientific.
I think its time for me to learn more about it. Briefly I want to know how do you come to the estimates, timewise, effortwise and resourcewise.

Suppose I get a Change Request from the Client, how do I go about estimation of it so that I can commit something to the client and Deliver it on time.

Thanks

Ajit Wadekar

[ May 27, 2004: Message edited by: Ajit Wadekar ]
[ May 27, 2004: Message edited by: Ajit Wadekar ]
Manish Hatwalne
Ranch Hand

Joined: Sep 22, 2001
Posts: 2578

Have you read The Mythical Man-Month and Peopleware : Productive Projects and Teams ? Don't miss them. The first one is an all time classic.

- Manish
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
While this is an interesting topic, it's more appropriate for the process forum, so I'm moving it there.

--Mark
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Ajit Wadekar:
What I use currently in my project is my past experience from the same project or discuss it with my manager and other people, which isn't scientific.

This, by the way, is what I do as well -- and it works very well, most of the time at least. The other school of thought would be something like function point analysis (which is still based on your analysis of the change request, by the way).

I can't help mentioning that "Yesterday's Weather" is what Extreme Programming uses for estimation. That's pretty close to what you and I seem to be doing.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
This is the method I recommend in my upcoming book. I have found it works extremely well....

1. Come up with your own estimates (possibly after talking to others). These may or may not be the same as the official estimates you give your boss.
2. Do you work and half way through each task re-estimate total time you expect it to take.
3. At the end of each task, record the actual time it took.

You'll begin to notice trends. Most junior developers for example, tend to be off by a factor of 2-3. Once you see the pattern, you can compensate for it.

Note that you need to continually do this, because once you start compensating, you still need to insure that you're on target, and not over- or under- compensating.

--Mark
Adnaan Sikandar
Greenhorn

Joined: Feb 05, 2004
Posts: 3
We use QSM SLIM-Estimate tool. Its works well for the planning stage. Basically, you enter parameters such as use case count, complexity, productivity index etc and SLIM generates the number of total man hours required for the project as well as the resource count and break down of hours by RUP phases.

For change requests, you can probably rerun the SLIM and compare the deltas.

SLIM Estimate
[ June 06, 2004: Message edited by: adnaan sikandar ]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
We do several levels of estimates. Our director talks to officer-level people and says "That sounds about as big as the last thing we did, that took about 6 months, so let's say from 5 to 8". Everybody knows he's talking without his techies along, so it's a guess. Maybe it's good enough to decide to do one project and not another, but not something to bet the farm on.

When customers get more interested, we take a next level estimate based on major functionality. We work with the customer to turn this into a use case catalog, maybe 0.5 or 1 day's effort together. We call each use case Small Medium, Large or ExtraLarge, run them through a spreadsheet that does some magic with manpower, duration, fixed costs, management overhead and puts out a +- 50% SWAG. This is considered reliable enough to get funding, but not to promise a complete date.

Then it gets real fun. We take a day or two with real users and their supervisors and make story cards, up to a few hundred. We push four or five long tables together, lay the cards all out in priority order, have a few key developers come through and give estimates in abstract story points. They don't even try to relate story points to days duration, they only compare one story to another. An 8 is twice as much work as a 4. But we do have the advantage of a stable team and we know how many points we do per week as a whole group. So we can see if the total points seem realistic with the manpower and time estimated before and adjust the date. First time with a new team you'd have no "yesterday's weather" and it would be hard to know if the date is good or not. This is probably right out of any XP book.

Then every two or three weeks we pull out some cards, estimate them again based on the prior weeks experience and start an iteration. Based on story points completed per iteration and points remaining we get a pretty good feel early on whether the end date is reasonable or not. Our customers love the story cards and understand the story point velocity and are very good about helping to renegotiate scope or dates if the earlier estimates turn out to be wrong.

Unfortunately for you, all this is based on prior experience. Most of the team has been together since 1996, working in the same business domain so we mostly know what to expect. Doing this from scratch with new folks would be scary! But the part you can use is to do the best estimate you can by whatever technique, then review and refine it often. XP and the agile methods give you very visible progress (or not) and help you steer your future direction together with your customer.

Wow, sorry that was so long. Hope something there was useful!


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Pieter Schmidt
Greenhorn

Joined: May 01, 2005
Posts: 5
Originally posted by Ajit Wadekar:
Hi

I don't know where to put this so I am putting my post here. I want to know more about the Software Estimation Methodologies available.
I am doing it for quite some time now but without any scientific or any formal methodology.
What I use currently in my project is my past experience from the same project or discuss it with my manager and other people, which isn't scientific.
I think its time for me to learn more about it. Briefly I want to know how do you come to the estimates, timewise, effortwise and resourcewise.

Suppose I get a Change Request from the Client, how do I go about estimation of it so that I can commit something to the client and Deliver it on time.

Thanks

Ajit Wadekar

[ May 27, 2004: Message edited by: Ajit Wadekar ]

[ May 27, 2004: Message edited by: Ajit Wadekar ]



Hi,

Check out this website, it has some good articles on estimation and a fully functional estimation tool for download based upon use case point estimation technique
http://liemur.co.uk/Articles/UseCasePointEstimation.html
Another article on Wideband Delphi technique is here:
http://liemur.co.uk/Articles/Wideband_Delphi.html

I have used the estimation tool on a project and found it very useful and easy to use.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Agile Estimating Tips might help.

- Scott


<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Stan James:
Unfortunately for you, all this is based on prior experience.


And I don't think it can work differently, because too much simply depends on things you can't reliably specify upfront, for example how well the developers will work together.


Wow, sorry that was so long. Hope something there was useful!


A great post, actually! Should be referenced somewhere in the FAQ, I guess...


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Valentin Crettaz
Gold Digger
Sheriff

Joined: Aug 26, 2001
Posts: 7610
Software by Numbers was not bad either:
http://www.coderanch.com/t/93634/Book-Reviews/Software-Numbers-Mark-Denne-Jane


SCJP 5, SCJD, SCBCD, SCWCD, SCDJWS, IBM XML
[Blog] [Blogroll] [My Reviews] My Linked In
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Software Project Estimation
 
Similar Threads
Offer from Big Five IT Firms in Pune
Job Change in India
Interview Functional Questions
Question about how to live my life (to show code or not to show code)
Design Questions