The final step in project cost estimation with use case points is to do the math. First you identify the technical and environmental factors that influence your environment and describe your team. Then you analyze the use cases and actors that describe the expectations of the software and who has them. Finally, you bring it all together to do the math.
Background
This is the sixth article in a series on applying use case points to create reliable software cost estimates. What makes use case points different is that they allow the project cost estimation to happen much earlier in the process. This cost estimation technique was developed by Gustav Karner for Rational Software Corporation in the mid 1990’s.
The introduction to software cost estimation is the right place to start if you came to this article first. In the previous article we discussed:
- Technical Factors of the Implementation. Characterizing (non-functional) requirements of the software.
- Environmental Factors. Describing the team and the process.
- Use Case Quantity and Complexity. Representing what the software is asked to accomplish.
- Actor Quantity and Complexity. Enumerating the users of the software.
Collecting The Use Case Point Data
Use the links above the abacus to review any of the calculations that you performed in the previous articles.
In the first step you determined a numerical representation of the technical factors for your software. This is the technical complexity factor, TCF.
In the second step you created a number representing the environmental factors that influence your team’s ability to get the job done. This is the environmental factor, EF.
In the third step you measured the use cases, creating a representation of the quantity and complexity of the use cases that the software must enable. This is the unadjusted use case points, UUCP.
In the fourth step you reviewed the users of the software – both people and other systems. This is the actor weighting, AW. [Note: Some articles refer to this as the unadjusted actor weight, or UAW].
Calculating The Use Case Points
The formula to calculate use case points is described below in terms of the variables from above: TCF, EF, UUCP, and AW.
Use Case Points = (UUCP + AW) * TCF * EF.
The total use case points equals the sum of unadjusted use case points plus the actor weight, multiplied by both the technical complexity factor and the environmental factor.
The next step is to convert this normalized representation of “how big the job is” into an estimate of effort.
Determining Effort From Use Case Points
This is the part where your math becomes an estimate of effort.
Unfortunately, this is where opinions can sneak in when you’re first using use case points. Different experts identify different values to use.
- Karner, the originator of the approach, suggests using 20 hours of effort per use case point.
- A case-study team, cited by Ed Carroll, found empirical data to support using 28 hours per use case point.
- Other estimates range from 15 to 30 hours per use case point, cited by Roy Clem.
Another approach proposed that “complex projects” have a higher conversion factor (28 to 1) than “simpler projects” (20 to 1). The following calculation determines if a project is complex:
For each of the following environmental factors that has a value below 3, add a point.
- 1. Familiarity with the project.
- 2. Application experience.
- 3. Object oriented programming experience.
- 4. Lead analyst capability.
- 5. Motivation.
- 6. Stable requirements.
For each of the remaining environmental factors that has a value above 3, add a point.
- 7. Part time staff.
- 8. Difficult programming language.
Add up the points. If you have fewer than 3 points, use 20 hrs per UCP. If you have 3 or 4 points, use 28 hrs per UCP. If you have 5 or more points, restructure the project.
This makes a lot of sense – it essentially says that inexperienced teams will take 40% longer to complete the project. And when there is a significant disconnect (between capability and expectation), the project should be reset – to lower expectations or increase capabilities or both.
Revise and Refine
The key thing to note is that these “generic” effort-to-UCP conversions are a starting point. You have to adjust them over time to improve the accuracy of your estimates. Maybe you will need to rethink what it means to be “experienced,” or just how difficult “difficult” is.
Use Case Points Can’t Be Proven To Work
This actually identifies a weakness in the approach – you can never prove that it works (or doesn’t). Essentially, you have one equation with two unknowns. If an estimate is proven wrong at the end of the project, it could be because the calculation-math is flawed, or it could be because the estimates along the way are flawed. If your estimates prove to be right, it could be because both are wrong, and the errors happen to cancel each other out.
Use Case Points Are Still Valid
Nonetheless, use case point-based software cost estimates are still reasonable. Producing an estimate with use case points will result in a greater likelihood of project success than any other estimate (that I know of) that can be performed at the same stage in the project, with the same amount of data. And the introspective act of calculating UCP at the beginning of a project will help find and avoid costly mistakes later in the project.
Save Time And Effort
[Update: Download our free excel spreadsheet for calculating use case points.]
Question about this series of articles…
Has anyone out there actually used this estimation scheme? If so, do you have some sort of Excel spreadsheet for doing the survey and calculations on each feature? I’d be interested to see what that would look like.
Also, how long is this process expected to take? It seems like estimation can take as long as you want it to take, but there’s a law of diminishing returns with resepct to time. Is this process crossing that line?
Okay, so why have an “expert” figure out that a point = a certain hour range? Why not ask the team? Why isn’t the team doing this estimating? Aren’t they the ones doing the work?
Patrick,
Thanks very much for reading and commenting! I owe you a thank you – my intent was to create the spreadsheet after finishing the tutorial, and I almost forgot. When I saw your comment it reminded me to get it done.
I think that there is very little incremental effort in creating an estimate this way – relative to the things you should be doing anyway. Identifying actors and use cases – that has to happen regardless. A little incremental effort to classify them.
The environmental factors shouldn’t take more than an hour to determine, in a discussion primarily with your development manager or dev lead.
The technical factors could take a couple hours to figure out – they require some insight into the project environment. I would contend that the insight exercise is valuable for future decision making, even if you don’t use it for the estimate.
You’re exactly right about diminishing returns. I feel that UCP provides a good “rough order of magnitude” estimate (+100%/-50%) with half a day of effort to organize and think as above. The original authors of the method felt like they could achieve +/- 10% data with this approach. I haven’t seen that happen. It may be possible, even realistic, but I’ve always seen projects get “big changes” early in the envisioning stage (where this is most useful), so I haven’t tried to narrow it down. I think there’s a danger of false precision if you do – the UCP calculation creates a number and people will remember it.
So, I would spend half a day (assuming use cases and actors are defined, which they should be anyway), and then use that for a ROM estimate.
Aaron,
Thanks for reading and thanks vry much for commenting!
You’re exactly right – ask the team. When I saw the numbers from the experts, my thought was “Great – I have a starting point. I’ll adapt that to my team as we get good data.”
If you can go back over historical data, and create a UCP estimate, and compare it with actuals, that would give you a number (to replace the “28”).
Thanks again!
Does use case estimation take care of the project management, requirement analysis and testing efforts also? Or is it effort and cost estimation for the design and development activities only?
Thanks, Rinesh!
The answer is “it can if you want it to.” That’s also how I would approach it. I have found that all of those elements tend to shrink and grow proportionally – e.g. complex use cases have complex testing requirements, and involve complex management activities more often than not. About the only thing that is decoupled is the project management overhead associated with interdependent use cases. Sometimes, a “very simple” use case may only be very simple to implement if several other use cases have already been implemented. Orchestrating and coordinating these entangled elements does add a level of complexity that a “per use case” analysis like this would not normally capture.
You can capture this information somewhat by adapting the complexity assignment to reflect interdependency. The problem is that the goal of estimating with use case points is to get insight early in the process – before those interdependencies can be discovered. And that weakens the value proposition of doing a use case points analysis at all, by making it a more involved process that requires data from “later in the process.”
Given that, I believe that while it can include other elements of delivering the full solution, it introduces increased error in the estimates due to the entanglement factor, if you also apply it to project management overhead.
Hi Scott
I think the nub of Rinesh’s question is: how was the figure of 28 in the spreadsheet calibrated? I would expect it to cover the technical effort, requirements, analysis and design, code and test, system test, but does it cover: project management, supervision/team leading, quality assurance, user acceptance, data migration, post live support etc etc. I would like to adopt the method and use the 28 metric as a starting point, but I would be keen to understand its provenance ie is it based on a wide variety of projects or is it a figure just used for illustration of the spreadsheet?
Thanks, John!
The 20 vs 28 is based on empirical data from Ed Carroll based on experiences with Agilis (company where he worked) and you can see his rationale here: http://www.edwrites.net/2005/10/estimating-software-based-on-use-case-points/ which includes a link to the paper he presented at OOPSLA 2005.
The differentiation between the two values (in their experience) comes from the added overhead that comes when projects are more complex, and usage scenarios have more interdependence.
According to Ed, the values of 20 and 28 are based upon over 200 projects with a team of 450 engineers. So, I think it is a good starting point for estimation, as long as you set expectations appropriately and adjust based on your own experiences.
Thanks to you and Rinesh for the great clarifying questions – they will help lots of folks who are keen to start trying to improve the predictability of their projects.
Scott (@sehlhorst on Twitter)
looking at user-acceptance-testing, what is the simplest method to calculate no. of hours & cost to be spent when looking at 300 test cases – for instance currently am working on some POS-project. My customer want to know how i derive my calculations. i don’t what to get to a stage whereby the whole thing escalates into a dispute.. Kindly advise.
Hey Washington, thanks for the question. Unfortunately, it’s been about a decade since I’ve done estimation at that level of detail. I have no idea what the best practice would be today – the best thing I could point you to is this methodology I outlined. It was the best thing I knew at the time I wrote it.
This article is old enough that I suspect many people don’t read the comments any more – but if someone has a suggestion, please chime in!
Best of luck!
Scott