Differentiating Between Estimating and Committing

"A fundamental and common problem in many organizations is estimates and commitments are considered equivalent.”
      —Mike Cohn
“Unless commitment is made, there are only promises and hopes; but no plans.”
      —Peter F. Drucker 

The difference between an estimate and a commitment seems simple: An estimate is an educated guess of how long it will take you to do something. It should not be thought of as a binding obligation. A commitment is an obligation to do what you say you will do.

In today’s fast paced and ever changing world, we are faced with the following variables:

More success + Greater speed + Fewer resources + Constant uncertainty + Increased competition + Quicker time to market + Highest quality

In light of this, it is not unrealistic to ask the agile-lean product development team early in the product development lifecycle to estimate how long it will take them to develop and deliver the product.

On the other hand, there is inherent uncertainty and complexity in system-software development; you just don’t know what you don’t know. Traditional approaches assert that uncertainty can be defeated by big requirements, big design, and big planning up front, but that is incorrect. Uncertainty is so high that to discover all of this up front is impossible. The familiar Cone of Uncertainty in figure 1 graphically represents this.

  Figure 1: Cone of Uncertainty 

This is why classic approaches, like waterfall, fail to effectively deal with uncertainty. This is whyearly in the product development lifecycle it is unrealistic to ask the team to articulate and commit to what it will take to get everything imaginable done. Effectively and realistically dealing with uncertainty is important. Some of the most common consequences of improperly dealing with uncertainty are false expectations and the inability to meet commitments.

Your agile-lean product development team exists within a larger enterprise-wide ecosystem of business goals, business people, and finance. If your agile team unilaterally adopts an agile-lean product development approach, you make things somewhat better, but you will not capitalize on your full potential and may end up frustrated and dissatisfied with the outcome. Therefore, we need to change the entire ecosystem’s understanding of what it really means to make an estimate (an educated guess for how long it will take you to do something) and a commitment (an obligation to do what you say you will do).

Agile-lean product development is based on iterative and incremental development. We plan a little, do a little, check how we have done, and adapt, as shown in figure 2. Asking your agile-lean development team to be both accurate and precise when estimating early in the product lifecycle, and asking team members to commit to how long it will take them to get the entire product done are the antithesis of the behavior we are trying to adopt.

Figure 2: Quality improvement cycle

Educated Guess Versus Obligation
Let’s start with gaining consensus on the words precision and accuracy as they relate to estimating:

The precision of your estimate describes the size of the unit you use to make the estimate. The smaller the unit, the more precise the estimate. For example, you might describe your height as “about six feet.” That is not very precise. If, however, you say you are “seventy inches tall,” that would be more precise. The smaller the unit you use for estimating, the more precise the estimate will be.

The accuracy of an estimate describes the difference between your estimate and the real value: The greater the difference, the less accurate your estimate. This real value need not 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 along faster, resulting in something of value being delivered frequently. The continual releases of the product have the potential to peak interest and increase the project's momentum. As each increment of the product is completed and released, the next product increment becomes a more attractive prospect for executives and the project sponsor, as x amount of work is already completed and the development effort is x amount of time closer to being finished.

When we base agile-lean product development on incremental funding and on objective demonstrations of working software instead of on milestones based on imprecise and inaccurate estimates, we have ongoing opportunities to assess and adjust. The result is delivering commercial or operational value early and often, giving ourselves the best opportunity to beat the competition to market, satisfy the customer, realize revenue early, and discover insights that we can use to help us improve.

In agile, lean commitments made to getting work done should be done incrementally, so you can quickly adapt to change and use resources effectively and efficiently throughout the product lifecycle. Therefore, incremental funding is advantageous when being agile and lean.

Final Thoughts
In agile and lean, accuracy (the measure of bias) and precision (the measure of spread) are very important when making a commitment for what you are going to get done in an iteration, but not so important when making an estimate for how long you think it will take you to develop and deliver the entire product.

It is realistic to ask the agile-lean product (system-software) development team early in the product development lifecycle to estimate how long it will take them to develop and deliver the product. It is unrealistic early in the product development lifecycle to ask for a commitment to getting everything imaginable done.

Many organizations, especially early adopters of agile-lean product development, have difficulty differentiating between estimating how long it will take to do something and making a commitment to do what you say you will do. They erroneously consider estimates and commitments to be equal. They assume the commitment to cost, schedule, scope, and quality equates to the estimate—it doesn't.