In fixed-price contracts, how can a story be "negotiable" and represent a starting point of conversation with business?
Think about it. When do you ask for the fixed-price? At the end, of course, when you know what you need to do and thus how much it will cost. If you are trying to mix Agile development with traditional fixed-price contracts then you are asking for trouble.
Time and Materials contracts are more appropriate when doing Agile development. If you want fixed-price with Agile, then you can use it for an initial test phase to build something for a (short) predetermined period, to see how things can work and how everyone likes it, and then decide on terms and conditions of a further contract, which will probably still be Time and Materials.
If you want the traditional fixed-price, then you need to have a lot of details about what needs to be built, upfront, so that you know how to price it. Using User Stories as a starting point for a conversation then placing a price on the result of the conversation - without having had the conversation - is just silly.
You can't afford to discover things as you go along with a fixed-price contract. If you do that you will carry a lot of risk of the result of the conversation being something completely different than what you initially priced. So there are mainly two options for dealing with this risk:
- set a very large price to cover anything imaginable (which might cause you to lose the contract because it will be very expensive);
- or try to predict a more realistic price by figuring out precisely what needs to be done (in which case that's not the start of a conversation but having a very comprehensive discussion of what needs to be done, with a lot of details).
Why is it "not agile" to know very well upfront what you need to do?
Agile is about iterative, incremental development. One of its principles says to "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale". A big upfront plan is usually a characteristic of more traditional software development methodologies. The idea there is that you predict what you need to build and how you are going to build it. You then make a plan and follow it. And you do this at the beginning of the project when you know least about the project. History has shown that this doesn't work all that well in practice. Agile just recognizes that fact.
Ironically, the initial Waterfall concept was also iterative. Its author mentioned that without iterating the approach was risky and invited failure. But you don't even need to read the original paper to realize this, because in real life, if you pay attention, you will see that Waterfall is also iterative:
- you do your "Requirements" stage but in the "Design" stage you find the problems with them and iterate.
- in "Implementation" stage you find issues with your design so you need to fix them. Maybe find issues with requirements also, and fix those too.
- in the "Verification" stage you find issues with your implementation and you need to fix them. You may also find issues with the design or the requirement, and you have to fix them.
People don't recognize this work as iterative because they work in stages. "Design" stage is over, now we are doing "Implementation", even though some of the work in "Implementation" might be to fix or iterate on issues from "Design", and so on.
So if the nature of software development forces you to iterate, why not start with that in mind, instead of wasting time to do a lot of upfront planning with heavy documentation to predict something that reality will contradict soon enough?