Russell Pannone writes that there is inherent uncertainty and complexity in system-software development; you just don’t know what you don’t know. 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.
"A fundamental and common problem in many organizations is estimates and commitments are considered equivalent.”
“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