Dear Carol:
I’m a developer in our IT department and we know that project estimating is a big deal for our customers. Somehow, no matter what we do, we can't seem to get it right. We do know that project size is an important input to good estimating and our gut feel is that if we get sizing right, we’ll do better estimates! I know you recommend using function points, but I’ve also been reading a lot about use case points, story points, SLOC, sizing by analogy, T-shirt sizing, COSMIC and other sizing metrics. We do a mix of waterfall, agile, iterative and even Kanban to do our projects so what’s the best choice for sizing to get the best results?
- Size Challenged in Milwaukee
Dear Size Challenged:
Sometimes I wonder if the internet and the proliferation of (mis)information is a good thing. Before the internet, our choices (for sizing or estimating or anything) were limited and we didn’t have such an overwhelming task to first sift through many options before taking action. Your list of software sizing choices is an example of this.
You are right that sizing is an important (maybe the most important) input to estimating, but before I recommend the “best” choice for sizing, I’d like to ask you, what may seem like an obvious question: “what is it you want to estimate?” This is not a flippant question – it is a critical one and merits consideration. Now, before you answer with "cost, effort and schedule," think about what is the object of estimation – a project, iteration, a sprint, a release, a use case or what? If you don’t know (the scope of) what you want to estimate, you can’t even begin to estimate the how (in terms of how long (duration), how much ($) or how much effort.)
Too often, we (including me!) go into estimating without really considering that consistency is the key to good estimates. If I want to estimate a project, what is this thing called “project” and does it match up with the definition of a project for the estimating tool or equation I am using.
Consider this: If I have a construction estimating equation (this is the basis of most software project estimating models) that defines a project consistent with the Project Management Institute (PMI) definition of project...
“Temporary endeavor undertaken to create a unique product or service.”
...and I want to know the duration, cost, or effort to do several use cases, the first step would be to ensure that the “several use cases” matches up with the definition of project. In fact, several use cases may or may not result in a unique product or service. A project starts with a known/defined product or service scope (which can be sized) and ends either at the end of development (i.e., installation) or after installation. If the “several use cases” will go through the project life cycle and result in a working product, then it would qualify as a project and I can then figure out the best inputs for the estimating model.
Specificity of what is included in a project is also an important consideration and is one that skews estimates all the time. For example, if it is unclear at the time of an estimate whether or not the development of a subsystem is to be included in an estimate, obviously an estimate that excludes it will be wrong if such work was to be included. This is similar to saying that we aren’t sure whether to include a family room in the house construction and so we exclude it from the estimating scope – obviously if the resultant project includes the family room area, the original estimate will be wrong. So, being specific (and documenting) what is included and excluded from the estimating scope is also critical to getting estimates right.
I hope that this makes sense. Any of the sizing methods you mention may be suitable for use in the estimating equation (it depends on the model or tool you are going to use) – but the first and most important step is to figure out what it is you are estimating.
Once you know what you want to estimate, the how to size your software becomes a matter of consistency. See the other posts in Ask Carol for how to select which sizing option best suits your needs.
QSM hosts a free advice column for software professionals who seek help to solve project management, communication and general software project issues. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!