Any process that combines unlimited "wants" with limited resources yields optimism. In the case of an agile development project without a bounded scope, master plan for delivering that scope, and an understanding of the "capacity for work" of the development team - results optimism.
As Kent Beck mentions
Optimism is the disease of software development, feedback is the cure.
So what kind of "feedback" is needed:
- What is the capacity for work? - How many stories, function points, features, capabilities can be produced for each period of measure. These periods can be weeks, months, quarters, maybe even days. But before this measure is meaningful, it needs to be calibrated.
- What is the business value of each produced item?
- Are the items of equal value or do they have variance in this value?
- If there is a variance, how big is it?
- What is the breakage rate for the produced products?
- While the ideal is to produce 100% working code, this is Unit Tested code.
- Integration tested code is the real measure of breakage.
- Breakage includes requirements breakage, performance breakage, and other non-unit test measures
- What is the increasing maturity of the developed items?
This last question is the key to success of any project. The keys are are several:
- Are we heading toward a successful outcome - the measures of success are usually defined by the customer in some units meaningful by the customer. Reporting stories per iteration may be meaningful to the developers (but remember stories are yesterday's weather and not really a good predictor of the future).
- Are the produced articles (configurable end items in a formal vocabulary) supporting the business case. The agile concept of "only building things of value needs a measure of that value. A measure in the same units as the business case that defined the project. Measuring the produced value is critical to the success of any project. Be it building a software system or build a machine capable of flying to the moon.
