I know it's not the "Agile way" and it often isn't done but I am advocating for leaving the details of core business decisions (e.g. how royalties are calculate

I know it's not the "Agile way" and it often isn't done but I am advocating for leaving the details of core business decisions (e.g. how royalties are calculated) to the people who's competence lies in this question: the business development and legal teams - and not the software development team to whatever is easiest to implement for them. The latter might not always be what's best for the business. If you are not doing that, you need many iterations to rediscover what's already known to the organization. > "Working software over comprehensive documentation" Working includes correctly working. As soon as you interface with the legal world this means to actually calculate whatever your business agreed to and not something else just because it's easier, produces some random numbers, and exists without printing to stderr. That's not working software. This typically can't be worked out by development teams themselves, for the reasons you mentioned. And that's exactly why some kind of spec (in whatever form necessary - probably not a document of hundreds of pages but also not a one sentence user story) is needed to capture that. That's what I mean by translating and I'm not proposing to leave that to some product manager. Of course this can also be fixed by adapting your contracts (which can be an enormous task) but for that you also need some documentation on whatever the system is doing (just as developers can't read contracts, lawyers can't read code) and will discover that many stakeholders won't agree to that and demand changes. This is all not to be confused with doing a big design of the technical architecture and all features beforehand.