Trail length is an estimate of size, while the time need to hike it is another story!
More than occasionally I am asked, “Why should we size as part of estimation?” In many cases the actual question is, “why can’t we just estimate hours?” It is a good idea to size for many reasons, such as generating an estimate in a quantitative, repeatable process, but in the long run, sizing is all about the conversation it generates.
It is well established that size provides a major contribution to the cost of an engineering project. In houses, bridges, planes, trains and automobiles the use of size as part of estimating cost and effort is a mature behavior. The common belief is that size can and does play a similar role in software. Estimation based on size (also known as parametric estimation) can be expressed as a function of size, complexity and capabilities.
E = f(size, complexity, capabilities)
In a parametric estimate these three factors are used to develop a set of equations that include a productivity rate, which is used to translate size into effort.
Size is a measure of the functionality that will be delivered by the project. The bar for any project-level size measure is whether it can be known early in the project, whether it is predictive and whether the team can apply the metric consistently. A popular physical measure is lines of code, function points are the most popular functional measure and story points are the most common relative measure of size.
Complexity refers to the technical complexity of the work being done and includes numerous properties of a project (examples of complexity could include code structure, math and logic structure). Business problems with increased complexity generally require increased levels of effort to satisfy them.
Capabilities include the dimensions of skills, experience, processes, team structure and tools (estimation tools include a much broader list). Variation in each capability influences the level of effort the project will require.
Parametric estimation is a top-down approach to generating a project estimate. Planning exercises are then used to convert the effort estimate into a schedule and duration. Planning is generally a bottom-up process driven by the identification of tasks, order of execution and specific staffing assignments. Bottom-up planning can be fairly accurate and precise over short time horizons. Top-down estimation is generally easier than bottom-up estimation early in a project, while task-based planning makes sense in tactical, short-term scenarios. Examples of estimation and planning in an Agile project include iteration/sprint planning, which includes planning poker (sizing) and task planning (bottom-up plan). A detailed schedule built from tasks in a waterfall project would be example of a bottom-up plan. As most of us know, plans become less accurate as we push them further into the future even if they are done to the same level of precision. Size-based estimation provides a mechanism to predict the rough course of the project before release planning can be performed then again, as a tool to support and triangulate release planning.
The act of building a logical case for a function point count or participating in a planning poker session helps those that are doing an estimate to collect, organize and investigate the information that is known about a need or requirement. As the data is collected, questions can be asked and conversations had which enrich understanding and knowledge. The process of developing the understanding needed to estimate size provides a wide range of benefits ranging from simply a better understanding of requirements to a crisper understanding of risks.
A second reason for estimating size as a separate step in the process is that separating it out allows a discussion of velocity or productivity as a separate entity. By fixing one part of the size, the complexity and capability equation, we gain greater focus on the other parts like team capabilities, processes, risks or changes that will affect velocity. Greater focus leads to greater understanding, which leads to a better estimate.
A third reason for estimating size of the software project as part of the overall estimation process is that by isolating the size of the work when capabilities change or knowledge about the project increases, the estimate can more easily be re-scaled. In most projects that exist for more than a few months, understanding of the business problem, how to solve that problem and capabilities of the team increase while at the same time the perceived complexity[1] of the solution decreases. If a team has jumped from requirements or stories directly to an effort estimate it will require more effort to re-estimate the remaining work because they will not be able to reuse previous estimate because the original rational will have change. When you have captured size re-estimation becomes a re-scaling exercise. Re-scaling is much closer to a math exercise (productivity x size) which saves time and energy. At best, re-estimation is more time consuming and yields the same value. The ability to re-scale will aid in sprint planning and in release planning. Why waste time when we should be focusing on delivering value?
Finally, why size? In the words of David Herron, author and Vice President of Solution Services at the David Consulting Group, “Sizing is all about the conversation that it generates.” Conversations create a crisper, deeper understanding of the requirements and the steps needed to satisfy the business need. Determining the size of the project is a tool with which to focus a discussion as to whether requirements are understood. If a requirement can’t be sized, you can’t know enough to actually fulfill it. Planning poker is an example of a sizing conversation. I am always amazed at the richness of the information that is exposed during a group-planning poker session (please remember to take notes). The conversation provides many of the nuances a story or requirement just can’t provide.
Estimates, by definition, are wrong. The question is just how wrong. The search for knowledge generated by the conversations needed to size a project provides the best platform for starting a project well. That same knowledge provides the additional inputs needed to complete the size, complexity, capability equation in order to yield a project estimate. If you are asked, “Why size?” it might be tempting to fire off the answer “Why not?” but in the end, I think you will change more minds by suggesting that it is all about the conversation after you have made the more quantitative arguments.
Check out an audio version of this essay as part of SPaMCAST 201
[1] Perceived complexity is more important than actual complexity as what is perceived more directly drives behavior than actual complexity.
Like this:
Like Loading...
Software Process and Measurement 