Traditional software development projects are executed in a value-neutral setting in which:
- Every requirement is treated as equally important
- The delivery of technical components is seen as of equal importance to the delivery of usable systems
- "Earned value" systems track project cost and schedule, not stakeholder or business value
- A "separation of concerns" is practiced, in which the responsibility of the development team is confined to turning software requirements into verified code rather than delivering business value
- The actual desired outcomes of the project are ignored in favor of implementing the largest number of requirements possible
No wonder so many projects fail to deliver the desired business results! Unfortunately this includes many iterative software development projects where the developers iteratively implement the requirements rather than delivering business value. Any management system that rewards things that are easily measured (like implementing requirements) without a clear and direct tie to business value delivered is headed down the wrong path.
Delivering value is not the same as delivering code: it is easy to deliver a lot of code without delivering much business value. The code delivered and tested must do something useful for the business. This is not the same as delivering what the business asks for - much of what is asked for is never used and delivers no business value. We clearly need a means for finding and implementing the requirements with the highest business value first, and separating wishes from real needs.
The key to understanding the business value derived is to map requirements back to the desired outcomes for the project: a requirement not related to a desired outcome is clearly not important to the business. The connection to iteration planning is that early iterations should implement requirements related to more important desired outcomes, with one clarification: technical risk cannot be ignored. This apparent conflict can be resolved by recognizing that desired business outcomes require that technical risks are resolved early because a technically infeasible solution is incapable of delivering any desired outcomes.
As a result, planning iterations entails choosing the right set of risks and requirements for each iteration to ensure that the iteration’s results make measurable progress toward the delivery of the desired business outcomes. As progress is demonstrated, as everyone can see that key technical issues are being resolved, and as the achievement of desired outcomes becomes increasingly apparent, confidence in success increases.