At XP day, I said that we no longer put any reference to scope in our contract. I was immediately challenged to explain, and targeted by a 'Heatseeking Action' - a practice we'd introduced only a few minutes ago - to do so by 12:03 on Thursday. So here are the details.

The contract represents a tiny subset of the communication that happens when a project starts up. By the time the contract's signed, we've agreed a vision, run a stories workshop, prioritised the backlog, drawn up risk factors, discussed likely velocity, and drafted an approximate release schedule. Collaboration is more important than contract, but - particularly for senior stakeholders - contract is still important, so here's what's in ours:

• An agreed day rate, with invoicing at the end of each sprint.
• A clause allowing the client to terminate the project at the end of any sprint.
• We have (in special situations) opted to include a clause which allows the client to terminate the project at any point in the first month and owe nothing. If this happens, they don't receive any IP rights.
• Guaranteed availability of a specified number of developers up to a specified date. Beyond that date, availability isn't guaranteed, since we need some advance notice to organise our schedule.
• A named development lead who is permanently assigned to the project, and a pool of named developers who can rotate into the remaining slots.
• A list of demo dates and times. Yes, these are written into the contract. We also provide a status report and risks update on these dates.
• A list of the responsibilities of the Product Owner, and the likely consequences of Product Owner failings. These aren't strictly contractual - there's no penalty clause - but we like the gravitas. This, combined with our Product Owner training, tends to give us very effective Product Owners.
• A section handling IP rights, including appropriate handling of open source.
• Some standard sections covering confidentiality, non-solicitation, force majeure, and so on.

I was deliberately provocative in our presentation, and later Pascal van Cauwenberghe took up the challenge. He creates contracts with about two pages (10%) of 'scope'. In his words, "The scope essentially describes what each of the stakeholders will be able to achieve when the application is done", down to a resolution like "The order manager can followup all transactions and correct any mistakes". This feels dangerous, albeit possibly necessary, to me: on one project, we've actually scrapped a large area of functionality in order to enhance the others, which by then were delivering much more business value.

Pascal also writes technical and functional constraints into the contract. To me, this seems useful (it certainly adds gravitas!), but not strictly necessary - the first story that doesn't meet these requirements "should" fail done-done testing, immediately bringing it to the team's attention.

I think there are plenty of approaches to this and no 'right' solution, but I'd love to hear other people's experiences. Do you put scope in the contract? Does it work?