(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
(10) Simplicity — the art of maximizing the amount of work not done — is essential.
Because of this emphasis on value, change, and simplicity, agile projects have a different approach to budget and cost management than traditional projects. This table highlights some of the differences.| Cost Management with Traditional Approaches | Cost Management with Agile Approaches |
| Cost, like time, is based on fixed scope. | Project schedule, not scope, has the biggest effect on cost. You can start with a fixed cost and a fixed amount of time, and then complete requirements as potentially shippable functionality that fit into your budget and schedule. |
| Organizations estimate project costs and fund projects before the project starts. | Product owners often secure project funding after the product roadmap stage is complete. Some organizations even fund agile projects one release at a time; product owners will secure funding after completing release planning for each release. |
| New requirements mean higher costs. Because project managers estimate costs based on what they know at the project start, which is very little, cost overruns are common. | Project teams can replace lower-priority requirements with new, equivalently sized high-priority requirements with no effect on time or cost. |
| Scope bloat wastes large amounts of money on features that people simply do not use. | Because agile development teams complete requirements by priority, they concentrate on creating only the product features that users need, whether those features are added on day 1 or day 100 of the project. |
| Projects cannot generate revenue until the project is complete. | Project teams can release working, revenue-generating functionality early, creating a self-funding project. |
When costs increase, project sponsors sometimes find themselves in a kind of hostage situation. A waterfall approach does not call for any complete product functionality until the end of a project. Because traditional approaches to development are all-or-nothing proposals, if costs increase and stakeholders don't pay more for the product, they will not get any finished requirements. The incomplete product becomes a kidnapped hostage; pay more, or get nothing.