Jan. 22, 2011, 6:04 p.m.
posted by concurre
Software projects produce numerous things that you can count. Early in the development life cycle, you can count marketing requirements, features, use cases, and stories, among other things.
In the middle of the project, you can count at a finer level of granularity—engineering requirements, Function Points, change requests, Web pages, reports, dialog boxes, screens, and database tables, just to name a few.
Late in the project, you can count at an even finer level of detail—code already written, defects reported, classes, and tasks, as well as all the detailed items you were counting earlier in the project.
You can decide what to count based on a few goals.
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. Number of marketing requirements, number of engineering requirements, and Function Points are all examples of countable quantities that are strongly associated with final system size.
In different environments, different quantities are the most accurate indicators of project size. In one environment, the best indicator might be the number of Web pages. In another environment, the best indicator might be the number of marketing requirements, test cases, stories, or configuration settings. The trick is to find something that's a relevant indicator of size in your environment.
Look for something you can count that is a meaningful measure of the scope of work in your environment.
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. For example, you might create a rough estimate based on a count of marketing requirements and then tighten up the estimate later based on a Function Point count.
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. If you're counting marketing requirements, be sure that what you counted as a "marketing requirement" for your historical data is similar to what you count as a "marketing requirement" for your estimate. If your historical data indicates that a past project team in your company delivered 7 user stories per week, be sure your assumptions about team size, programmer experience, development technology, and other factors are similar in the project you're estimating.
Find something you can count with minimal effort All other things being equal, you'd rather count something that requires the least effort. In the story at the beginning of the chapter, the count of people in the room was readily available from the ticket scanner. If you had to go around to each table and count people manually, you might decide it wasn't worth the effort.
One of the insights from the Cocomo II project is that a size estimation measure called Object Points is about as strongly correlated with effort as the Function Points measure is but requires only about half as much effort to count. Thus, Object Points are seen as an effective alternative to Function Points for estimation in the wide part of the Cone of Uncertainty (Boehm et al 2000).