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)

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.

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!

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.

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?