Pat O'Toole's Dos and Don'ts of Process Improvement: DO Generate Size Estimates, Naturally
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
#14: DO Generate Size Estimates, Naturally
Take your best shot at estimating the following:
The distance from Boston to Los Angeles;
The weight of a midsize car;
Minneapolis' average temperature in August.
That wasn't so hard now was it? Oh, but did I mention that I wanted the distance estimated in furlongs, the weight estimated in stone, and the temperature estimated in degrees Kelvin? The estimation exercise was much easier when you implicitly selected your own "natural" units of measure; it became a bit more challenging (or tedious) when you were forced to use my "unnatural" units.
Many organizations, especially those that use the CMM as their process guide, require size estimates to be generated during project planning. In the quest for organizational consistency, "Level Three-ness," or external benchmarking, some groups have restricted the units of measure for these estimates – e.g., software size must be estimated in either source lines of code (SLOC) or function points (FP).
Toward the end of the last century, I used to derive perverse pleasure from asking pure function point shops how they could justify person-centuries of effort for their Y2K project - a project adding zero function points! Unfortunately, for many software engineering environments, SLOC and FP are unnatural units. Groups doing object-oriented development, those using code generators and/or enjoying high levels of re-use, and support groups performing "break and fix" maintenance work are frustrated when forced to use SLOC or FP to estimate the size of their projects. For these groups, SLOC and FP do not correlate in any meaningful way to the amount of effort and schedule required to execute their projects.
Rather than constraining size estimation by imposing unnatural units of measure, organizations would be much better served by having the estimators focus long and hard on the basis of their effort and schedule estimates. That is, what are those project attributes that, in the mind and heart of the estimator, lead to higher/lower levels of effort or longer/shorter project schedules? Are they thinking about:
The complexity of the programs to be written or modified?
The number of application system interfaces?
The technologies to be used to generate the software solution?
The number of platforms on which the system must run?
The amount of reusable code or functional components?
The number of peer reviews required for both code and non-code work products?
The number and types of tests that must be run?
Similar projects that have been conducted in the past?
Other things?
Get the developers and project managers to document the natural estimation parameters as the basis of their effort/schedule estimates, and call them "size" for that project. Collect and share these attributes across project teams to heighten people's awareness to the robust set of attributes that are being considered across the various projects. By empowering the estimators to focus on appropriate units of measure they should cease their unnatural estimating "sighs" and start estimating size naturally!
One last tidbit - you were close if you estimated about 12,000 furlongs, 225 stone, and 305 degrees Kelvin.
Copyright (c) Process Assessment, Consulting & Training 2002
For more information contact:
PACT
1316 Summit Oaks
Burnsville, MN 55337
Toll free: (877) 432-PACT (7228)
Cell: 612-387-PACT (7228)