wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes Estimating a Project 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 "Estimating a Project" Watch "Estimating a Project" New topic
Author

Estimating a Project

kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1373
What documents form the base for estimating(cost, man-hours, schedule) a project? For eg Requirement Spec, Design Doc, .....
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Documents like requirements specifications give you a rough idea of what you need to build. Past experience building similar systems tells you how long or how much effort it will approximately take. Estimating is the act of pulling these two resources together into an informed guess also known as "the estimate."


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Understanding what needs to be build and breaking it down into estimable chunks - that is what forms the base for estimating a project.

Note that the understanding doesn't have to come from documents; actually it could be argued that a discussion between those who know what they need and those who know how to build it, like in the XP Planning Game, often works better.


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
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
You might find Comparing Approaches to Budgeting and Estimating Software Development Projects and Agile Project Planning Tips useful.

- 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>
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
I just posted the initial draft of The "Broken Iron Triangle" Software Development Anti-pattern and would appreciate feedback.

Thanks in advance.

- Scott
Don Morgan
Ranch Hand

Joined: Jul 24, 2003
Posts: 84
From the requirements and the design, along with much discussion, you can come up with a task list. Once you have a fairly detailed task list, think about who will do the work and task dependencies if you want to derive a detailed schedule.

Some points on consider:

* the smaller and more detailed the tasks in your list, *usually* the more accurate the overall estimate, but then more work is required to do the estimate.
* plan to reassess the schedule periodically, it will change as the project progresses
* knowing what needs to be done is, at best, only half of the information you need. Who is performing the work will have a huge impact on the schedule.
* include holidays for your developers. Also, as a general point, calendar time and estimated work time to complete a task are different; business people usually think about the former and developers usually think about the latter.
* include a good sized contingency (doubling the estimates is surprisingly common)
* include adequate time during iterations for bug fixes
* include time for new staff to come up to speed, especially if you are modifying an existing system


Don Morgan, Founder
www.DeveloperAdvantage.com - FREE Audiobooks for Software Developers
Svend Rost
Ranch Hand

Joined: Oct 23, 2002
Posts: 904
Hi,

as Ilja mentioned understanding what needs to be done should be the base
of your estimate. A good place to start is making an architecture of the
system - from the derived structures you shold get a good idea of what
has to be done.

@ Scott: I havn't had time to read your article yet, so I can not comment
on that, but I just wanted to mention an article by Atkinson called
"Project management: cost, time and quality, two best guesses and a phenomenon" which (also) deals
with the short commings of the Iron triangle. It might be of interest to you.

/Svend Rost
[ March 01, 2006: Message edited by: Svend Rost ]
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Originally posted by Don Morgan:
Some points on consider:

* the smaller and more detailed the tasks in your list, *usually* the more accurate the overall estimate, but then more work is required to do the estimate.

And the smaller and more detailed the tasks in your list, the more likely they are to become obsolete/wrong before you get to actually implementing them.
Scott Ambler
author
Ranch Hand

Joined: Dec 12, 2003
Posts: 608
Then you should do the estimating at the point when you're about to do the actual work.

An interesting question:
What's more important to you: trying to get an estimate up front which you know will more than likely be wrong, or spending your money wisely by managing the project properly?

- Scott
Don Morgan
Ranch Hand

Joined: Jul 24, 2003
Posts: 84

And the smaller and more detailed the tasks in your list, the more likely they are to become obsolete/wrong before you get to actually implementing them.

Change is fine. Keep in mind we are talking about a task list for estimates, not implementation level requirements. Estimates for smaller pieces of work are generally more accurate than estimates for larger pieces of work and usually lead to more accurate overall project schedules.

Without adding some detail to our discussion, I am not sure how much we agree (or disagree). This will vary a lot from project to project, but here are my thoughts:

* if the overall project is person-months of effort, try go down to the level of detail of days per task

* if the overall project is person-years of effort, try go down to the level of detail of weeks per task

Do you think this is too detailed?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
Don, I don't think we're disagreeing that much about the granularity of the "tasks" to estimate. I think we might have different preferences regarding how big a portion of the whole system we would break down to the "task" level for estimating in the first place. What I'm trying to say that I don't feel comfortable breaking something into tasks of even several days a piece if I'm not even sure that those tasks will be needed.

As usual, there's a balance to strike somewhere between saying the first number that comes to mind and implementing the system first before saying how long it will take. Without a context, there won't be any "right" answers to the question of "how to estimate". In fact, even with a context, there won't be any right answers.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Estimating a Project