>If a potential client tells you they've got ${insert amount here} to spend and asks you what you think you can deliver to them for that price, "whatever you've got at the deadline" is usually a non-starter.
But isn't that the core of the agile software development philosophy? You, the client, turn your requirements into (somewhat independent) stories and prioritize them. We, the developers, take those stories and implement them in priority/dependency order. We ensure that the software is working at the end of every sprint (via extensive automated unit and integration tests). This means that you can cut the project off after any $n number of sprints and know that you're getting a level of functionality proportionate to the time that was spent on the project.
Yes, but you need a special client for that. I'm starting to get one to accept sprints, but it's taken 2 years. The rest think sprints are a great excuse for me not to deliver and need another $X000 to finish the work (fair enough, I wouldn't trust a car mechanic/builder/plumber working on this system)
Besides, clients always underestimate the time something takes. Expectation management is an oft-forgotten sibling to estimating. And when you're pitching for work, if others are promising to deliver everything for $Y and I offer a sprint-based system... as someone else commented, I've lost the project by then.
>> This means that you can cut the project off after any $n number of sprints and know that you're getting a level of functionality proportionate to the time that was spent on the project.
Telling them $n sprints can be meaningless -- in practice, things just get pulled out of a sprint and pushed into the backlog, never to get done within $n sprints.
I worked on one project where the client specifically asked for "agile". Meanwhile, their behaviour during the execution phase was that they wanted to see waterfall style results.
It wasn't until the PM finally switched back to a waterfall that the project started seeing meaningful results-- i.e., the "let's move it to the backlog" tactic used by the technical team could no longer take place.
Of note is that this is the classic story of a company that adopts "agile" despite the fact that the culture of its employees did not suit the methodology.
But isn't that the core of the agile software development philosophy? You, the client, turn your requirements into (somewhat independent) stories and prioritize them. We, the developers, take those stories and implement them in priority/dependency order. We ensure that the software is working at the end of every sprint (via extensive automated unit and integration tests). This means that you can cut the project off after any $n number of sprints and know that you're getting a level of functionality proportionate to the time that was spent on the project.