# Differentiating Between Estimating and Committing

[article]

be very precise; it just needs to be the accepted correct value. For example, we learned in math class that pi is a mathematical constant whose value is the ratio of any Euclidean plane circle's circumference to its diameter. This is the same value as the ratio of a circle's area to the square of its radius. It is approximately equal to 3.14159265 in the usual decimal notation. You do a careful measurement by drawing a circle and measuring the circumference and diameter, and then you divide the circumference by the diameter to get a value for pi of 3.14. The accuracy of your answer is how much it differs from the accepted value.

Furthering our understanding of the difference between precision and accuracy, suppose you are aiming at a target, trying to hit the bull's eye with twelve darts. Figure 3 shows the results.

Figure 3: Accuracy versus precision

Accurate but not precise : The darts are not clustered, but their average position is the center of the bull's eye.
Precise but not accurate
: The darts are clustered together but did not hit the intended mark.
Not accurate or precise
: This pattern is random. The darts are not clustered together and are not near the bull's eye.
Both accurate and precise
: The darts are tightly clustered with their average position in the center of the bull's eye.

Funding: One-time and Incremental
Let’s apply what we just learned about precision and accuracy and tie this back to agile-lean product development and making an estimate and a commitment.

First, you must determine whether your organization uses a one-time funding model or incremental funding model, as this has a direct bearing on how precise and accurate your estimate needs to be.

One-time funding means the entire project is funded without additional funds anticipated at a later date. Project completion risk is one of corporate finance’s big concerns. Project sponsors do not want to put money into a project that has a possibility of running out of further funding and ending up half-completed. The one-time funding model mitigates this concern by assuring that no funding will be allocated until the total cost, schedule, and scope of the project has been determined.

In the one-time funding model, you are tasked—early in the product development lifecycle—with estimating cost, schedule, and scope for the entire project knowing there will be no additional funds. To do this with confidence, the team feels the need to create detailed plans that justify its estimate. Traditionally, this is done via a work breakdown structure, which decomposes the entire work effort into a series of tasks in fine enough granularity so individual tasks can be confidently estimated with acceptable precision and accuracy. Completion milestones are identified and the estimates for each task are summed up to provide the final estimate. This works reasonably well if you are trying to estimate the cost of building an apartment complex. However, it doesn’t work very well for system-software development because business priorities will change and uncertainty is high, leaving ROI a big gamble. In the end, this approach is the exact opposite of the behavior we are trying to adopt with agile development, which is based on iterative and incremental development.

Incremental funding is defined as the partial funding of a project with additional funds projected at a later date. An incremental funding model breaks the development into minimal marketable feature sets (see sidebar) to be funded and delivered one set at a time. This method is advantageous because the development start-up cost is lower, and the development effort will move