Agile Zone is brought to you in partnership with:

Jurgen Appelo calls himself a creative networker. But sometimes he's a writer, speaker, trainer, entrepreneur, illustrator, manager, blogger, reader, dreamer, leader, freethinker, or… Dutch guy. Since 2008 Jurgen writes a popular blog at, covering the creative economy, agile management, and personal development. He is the author of the book Management 3.0, which describes the role of the manager in agile organizations. And he wrote the little book How to Change the World, which describes a supermodel for change management. Jurgen is CEO of the business network Happy Melly, and co-founder of the Agile Lean Europe network and the Stoos Network. He is also a speaker who is regularly invited to talk at business seminars and conferences around the world. After studying Software Engineering at the Delft University of Technology, and earning his Master’s degree in 1994, Jurgen Appelo has busied himself starting up and leading a variety of Dutch businesses, always in the position of team leader, manager, or executive. Jurgen has experience in leading a horde of 100 software developers, development managers, project managers, business consultants, service managers, and kangaroos, some of which he hired accidentally. Nowadays he works full-time managing the Happy Melly ecosystem, developing innovative courseware, books, and other types of original content. But sometimes Jurgen puts it all aside to spend time on his ever-growing collection of science fiction and fantasy literature, which he stacks in a self-designed book case. It is 4 meters high. Jurgen lives in Rotterdam (The Netherlands) -- and in Brussels (Belgium) -- with his partner Raoul. He has two kids, and an imaginary hamster called George. Jurgen has posted 145 posts at DZone. You can read more from them at their website. View Full User Profile

Fixed Price Contracts in Agile Projects

  • submit to reddit
Again and again I am asked (or feel compelled) to explain why agile software development fits nicely with fixed price contracts. Some people still think that a fixed price contract requires a detailed up-front requirements study, to accurately calculate the costs of the project. But that's not correct.

These are the arguments that I use frequently:

  1. In all the so-called "requirement studies" that I have seen (for fixed price contracts), I have never come across a proper description of the final product, as it has been delivered to the customer. It appears that, in all our software projects, customers change their minds, and we are simply expected to accommodate for that. Therefore, a detailed requirements study is not the best way to calculate the costs for a fixed price project. It turns out that the details are simply never correct! In fact, it might be easier to base our fixed price calculations on the weather, as it is more predictable than our customers.
  2. A fixed price contract requires only that the scope of the project is constrained so that we are confident enough to carry the risks. You don't need to know the exact length of the third field on the fifth input form on page 283 to do proper risk management. A simple set of high-level requirements is usually sufficient to reduce risks to a manageable degree. We just let the customer know that we're estimating two days for that ordinary customer contact form that he so desperately wants in his product. (And this form is highly unlikely to cost us more than four days.) That's all you need to know when signing the contract.
  3. For fixed price projects it is essential that you are able to constrain the scope (even more than with time-and-material contracts). With changing requirements (which are a fact of life) it is best not to have detailed requirements. From a psychological viewpoint, it is much easier to throw away old requirements, replacing them with new ones, if you haven't wasted time on any details. Oh, you also want a FAQ list in the product? Fine, but we won't have time for the contact form then. Is that ok with you? We couldn't care less, because we had only spent 30 seconds on the requirements anyway...
  4. If you agree on a fixed price contract using high-level requirements (like user stories), you retain the option of negotiating the details of the requirements. If the details of user story A cost you more time to implement than you had expected, then you have the option of implementing user story B later in the project using the simplest interpretation possible. Yes sir, we understand that you had expected the contact form to include support for smileys, attachments and spell-checking. But the import of your product catalog over a 14.4k modem from the backside of the moon cost us more effort than we had expected. (And we're still delivering according to the minimal specifications.)

For time-and-material contracts, working with user stories, or some other form of high-level requirements, is the smart thing to do. Many agile experts have already explained this a zillion times. But for fixed-price contracts, fixing the scope using high-level requirements, and not detailed requirements, seems even more crucial to me. The need to throw away old requirements is much higher, and detailed requirements do not enable you to re-negotiate the work that is involved to implement them.

Originally posted on NOOP.NL: Managing Software Development

Published at DZone with permission of its author, Jurgen Appelo.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)