First, let me say how much i enjoy reading posts to this group. I've learned a great deal lurking here. Thanks. Back to topic...
It seems to me that there is one artifact that BAs, UXDs and Devs can and should collaborate on early on, and that is the object model or ontology of the domain.
It amazes me how often the metaphor used to generate the object model is wrong, and how significant a difference fixing it makes to not only code quality, but also usability.
We call this different things, but I do think that the same model is expressed in an IA, or navigational structure, as in a data model, or more or less implicitly in the business requirements.
Interestingly, a focus on capturing all the user stories or paths through the system does not help with clarifying this model (though testing the relative priority of user stories with actual users may help to reveal a better domain metaphor, by shifting the primary context of objects users act on)
Maybe what's required to complement the more user-centred approach of agile development is a more object-orientated approach to user experience?
I could be wrong about this, but it's also tempting to suggest that the object model is particularly hard to improve iteratively. I think this is because the kind of stories you tell about users are restricted by it. Actions are like judgements, while object types are the ontology within which those judgements are formed. Worse, users will themselves adopt the implicit ontology of the system they are using, which often makes it difficult to tell when their difficulties are catastrophic, in the sense of compromising the entire conceptual scheme.
And for that very reason, it's best not to leave the definition of that model to any one of UX, BA or Dev - they all bring different sorts of constraints and intuitions that must be reconciled in the domain model, and they all need to buy into the same metaphor to ensure that they can validate it within user, business and system contexts.
Experience Architect, Profero Sydney