16.2 Flow of an Individual Estimate on a Well-Estimated Project


16.2 Flow of an Individual Estimate on a Well-Estimated Project

If the estimation inputs and process are well-defined, arbitrarily changing the output is not a rational action. Project stakeholders might not like the output, but the appropriate corrective action is to adjust the inputs (for example, reduce the project's scope) and to recalculate the outputs, not just to change the output to a different answer.

Figure 16-2 shows the flow of an estimate on a well-estimated project.

image from book
Figure 16-2: Estimation on a well-estimated project. The inputs and process are well defined. The process and outputs are not subject to debate; however, the inputs are subject to iteration until acceptable outputs are obtained.

In a well-estimated project, specific inputs of technical scope, priorities, and constraints are considered. These inputs can all be adjusted until the estimation process produces an acceptable outcome. Historical data is also an input to the estimate and is used to calibrate the productivity assumptions. Historical data is shown entering the bottom of the diagram because it shouldn't be adjusted in the context of a specific estimate—especially not to make the estimate come out to a specific result.

The estimation procedure itself is standardized. In other words, it is a procedure that is defined in advance of the need to create any specific estimate. Because it is standardized, it is not adjusted on an estimate-by-estimate basis—again, especially not for the purpose of moving the estimated results closer to the desired results. We'll discuss specific standardized estimation procedures in Chapter 17.

The outputs of estimated effort, schedule, cost, and features flow from following a defined process that uses defined inputs. On a well-estimated project, the outputs are not debated or scrutinized per se.

Differentiating between estimates, targets, and commitments is especially useful in this context. If the estimate is not what is desired, project leadership might nonetheless have good reasons to commit to achieving a target that is more aggressive than the estimate. But that doesn't change the estimate itself.

Within the estimation procedure, the only factor that ever needs to be estimated in the traditional sense (that is, by using judgment) is size. And you'll need to use judgment to estimate size only very early in a project, before you have requirements, stories, use cases, or something else you can count. Effort is computed from the size estimate by using historical productivity data. Schedule, cost, and features are computed from the effort estimate. Figure 16-3 shows this flow.

image from book
Figure 16-3: Flow of a single estimate on a well-estimated project. Effort, schedule, cost, and features that can be delivered are all computed from the size estimate.

Tip #70 

Focus on estimating size first. Then compute effort, schedule, cost, and features from the size estimate.




Software Estimation. Demystifying the Black Art
Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
ISBN: 0735605351
EAN: 2147483647
Year: 2004
Pages: 212

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net