How to properly estimate a Java project

One of the most difficult jobs in IT is how to estimate time and resources for a specific initiative. Software development in particular is even more difficult than say an infrastructure project because infrastructure projects don’t typically deal directly with the business and end user communities. The scope of software development projects often changes, right up until the final mad scramble of production deployment, causing cost and time overruns and exhausted developers. So how can these common issues be avoided?

Start out with use cases

Properly estimating a Java development project is both an art and a science. Since Java and the J2EE specification are built for enterprise-class solutions, it only makes sense to take an enterprise strength approach to assessing project size and cost. This means doing some upfront analysis before a line of code is ever written and you can do that by starting out with a use case-based approach.

A use case is a description of something a system does in response to an action from an actor, an actor typically being an end user. Use cases map very well to the agile artifact of a user story. This means once you have identified and analyzed (and yes, documented) as many of the use cases for the project initiative that are known by feature and function, you can create user stories as input to an agile-based development cycle.

Ensure accurate use cases

When writing use cases, it’s easy to lump in technical and physical design assumptions along with high-level features and function. Take the following use case for example:

“The system will allow application administrators to limit system load by setting rules that prohibit report execution for groups of users or redirect their execution to a batch stream.”

Several assumptions are made, namely the fact that it is assumed that the system cannot scale to handle the load so a feature must be built to manage the assumed limitation. A better way to write the use case would be something like this:

“The system will support up to 200 concurrently running reports with a maximum daily volume of 500,000 reports.”

The more accurate the use case is and the fewer assumptions it has makes for better user stories and less scope churn while the project is in development.

Basics of estimating

Once the use cases are developed, the project scope can be finalized and the estimating can begin. Start by estimating in terms of the slowest person on the team. Some developers take more time than others to complete a task but let the developers estimate coding and unit test tasks as they are best equipped to do so.

Also consider the time it may take to setup development, testing and production environments. These tasks can suck up a lot of otherwise productive time if not done upfront or during a planned activity.

Now it’s time to guestimate. No project estimate can be exactly known upfront but by using the following estimation algorithm, you can get a reasonably close first cut.

• Step 1: Determine the number of web pages, screens, database tables, interfaces and conversions required for each use case. Not all items will be in every use case. Consider one and a half man-weeks per page or screen, three man-weeks for each interface, one man-week for database tables, and one-man-week for converted data. Estimating man-weeks is more accurate by the number of objects created but we don’t have that data yet.
• 
  
• Step 2: Estimate coding and unit testing for each use case. Using the estimates from step 1, you can easily calculate a base estimate for multiple use cases. For example, for a series of use cases that contains four web pages, two interfaces, five database tables and no data conversions, the estimate looks like this:
  • (4 x 1.5) + (2 x 3) + (5 x 1) + (0 x 1) = 17 man-weeks or 680 hours.
• 
  
• Step 3: Multiply the result from step 2 by 2.5 so you can account for analysis and testing of each use case. So doing the math, we would now have 1700 hours as a project estimate.
• 
  
• Step 4: Add 20% to the estimate for each additional developer more than one. The base estimate assumes only one developer. By adding more developers, there is an inherent overhead for communication and coordination between team members. Let’s say we have 3 developers so we need to inflate the estimate by 40% (two additional developers). Multiply the base estimate by 40% and add that number to the base estimate like this:
  
  • 0.4 x 1700 = 680 hours
  • 680 + 1700 = 2380 total hours 
• 
  
• Step 5: Take a few minutes to go over the final estimate with the developers to see if it makes sense and refine as needed before committing the estimate to management.

Conclusion

The estimating process described assumes that your IT team uses a use case-based approach as part of its project management process. Use cases are generally found to be the best all around method of beginning the estimating process for Java projects. Subsequent refinement after the initial estimation using this method should be revisited at key milestone delivery dates to ensure the estimates are still valid. As with any estimating method, your mileage may vary. Feel free to experiment with different man-week values and adjust the estimate accordingly.