Estimating OO Projects

Related Sites

Myself and a colleague are currently trying to estimate the analysis and design phases of a 'small-to-medium' Java project.

We've been told we can have 10 people for a year, for the whole analysis, design, construction and testing phases but other than that we know nothing.

[...]

The problem with doing all your OOAD prior to construction is that the OOAD process does not generate any feedback for you to measure your progress. How "done" are you when you are 1 month into OOAD? Are you 10% done with the project?

A better approach, and one that most methodologists support, is to split the project up into a series of iterations. Do the OOAD for each iteration only when that iteration is scheduled.

If you have 10 people and 12 months, you might consider chopping up the project into 17 iterations of three weeks each. End each iteration exactly on time. Select features to be developed at the beginning of each iteration, and do analysis and design and construction of those features within the iteration.

After a two or three such iterations, you will have a very good idea of how fast your team can go, and what you will have done after the last iteration. And after every iteration you can improve your estimates and projections. You will have data!

To hedge your bets, make sure you work on the most important features first. At the beginning of each iteration, ask the business folks what features they'd like to see. Work on those features only. This way the business folks get the most important stuff done first. From their point of view you are always working on the things that mean the most to them. Moreover, every three weeks you show them a system that does what they asked for.

Measure how much you got done in each iteration. Don't agree to do any more in the next iteration than you got done in the last. Allow your data to drive your estimates. Make estimates that are supported by your data.

At the end of your 12 months you may or may not have everything done. However, you will have the most important things done. You will have reported your progress and velocity to the business guys at least seventeen times; the schedule will be no surprise to them. You will know the capabilities of your team, and be in a much better position to estimate future projects that use them.

ootips, Extreme Programming

ADM, Scrum Development Process

Alistair Cockburn, Using "V-W" Staging to Clarify Spiral Development

Robert C. Martin, Iterative and Incremental Development II

Kent Beck and Martin Fowler, Planning Extreme Programming

Alistair Cockburn, Surviving Object-Oriented Projects