Count, Compute and Judge
In this post, will be writing on some tips on how to count, compute and judge when doing an estimate.
Find something to count that’s highly correlated with the size of the software you’re estimating. If your features are fixed and you’re estimating cost and schedule, the biggest influence on a project estimate is the size of the software. When you look for something to count, look for something that will be a strong indicator of the software’s size.
Find something to count that’s available sooner rather than later in the development cycle. The sooner you can find something meaningful to count, the sooner you’ll be able to provide long- range predictability. The count of lines of code for a project is often a great indicator of project effort, but the code won’t be available to count until the very end of the project. Function Points are strongly associated with ultimate project size, but they aren’t available until you have detailed requirements. If you can find something you can count earlier, you can use that to create an estimate earlier.
Find something to count that will produce a statistically meaningful average. Find something that will produce a count of 20 or more. Statistically, you need a sample of at least 20 items for the average to be meaningful. Twenty is not a magic number, but it’s a good guideline for statistical validity.
Understand what you’re counting. For your count to serve as an accurate basis for estimation, you need to be sure the same assumptions apply to the count that your historical data is based on and to the count that you’re using for your estimate Find something you can count with minimal effort. All other things being equal, you’d rather count something that requires the least effort.
The following table provides an example of what can be counted
| Quantity to Count | Historical Data Needed to Convert the Count to an Estimate |
|---|---|
| Engineering requirements | Average number of engineering requirements that can be formally inspected per hour |
| Average effort hours per requirement for development/test/documentation | |
| Function Points | Average development/test/documentation effort per Function Point |
| Average lines of code in the target language per Function Point | |
| Change requests | Average development/test/documentation effort per change request |
| (depending on variability of the change requests, the data might be decomposed into | |
| average effort per small, medium, and large change request) | |
| Marketing requirements | Average effort hours per requirement for development or independent testing or documentation or creating engineering requirements from marketing requirements |
| Features | Average effort hours per feature for development and /or testing |
| Function Points | Average development/test/documentation effort per Function Point |
| Average lines of code in the target language per Function Point | |
| Engineering requirements | Average number of engineering requirements that can be formally inspected per hour |
| Average effort hours per requirement for development/test/documentation | |
| Stories | Average number of stories that can be delivered in a particular amount of calendar time |
| Defects Found | Average effort hours per defect to fix |
| Average Effort hours per defect to regression test | |
| Lines of code already written | Average number of defects per line of code |
| Average lines of code that can be formally inspected per hour | |
| Average new lines of code from one release to the next | |
| Test Cases written | Average amount of release stage effort per test case |