"The idea of having a ubiquitous language that everyone in the team used to describe acceptance tests was another good idea that came out of discussions – although I think if a team is developing software using a Domain Driven approach then this is likely to happen anyway."

Thats an interesting point, my experience with user stories in general was that they don't follow the UL to a large extent mainly because they often come from the user not the domain expert:

http://codebetter.com/blogs/gregyoung/archive/2007/10/16/bdd-and-the-shared-language.aspx

Depends though, if the domain expert is involved in the story (or acceptance criteria) development then maybe you get a lot more shared language.

"The idea of the UI being outside the bounded context that our domain model is used in was also suggested which strikes me as a good idea – would be good to see it done in practice though."

Not 100% sure what you mean here, bounded contexts really relate to the model itself so I'm guessing you mean in terms of having an anti-corruption layer (presentation model) between the domain and GUI?

"There was also discussion around the use of Data Transfer Objects, with the general consensus being that using DTOs was good around the UI to save you having to deal with incomplete domain objects around these areas."

Thats definitely part of it but I'd say the ability to change the domain without having a big ripple affect through the GUI(s) is equally important. Not least as you don't want to have to spend days/weeks changing the associated GUI(s), changing a little bit of mapping logic is much easier.

In addition its a pity that we go to all this effort to shield the domain from the database but in practice the GUI can cause as much if not more polution in a complex domain model.

In any case, this is not prescribing the way that people implement software — you can (and should) still keep implementing the software using the best practices that you are using at the moment. AAT is more about ensuring that we all agree on what we need to implement and ensure that we all understand it the same way.

I'm doing a talk on this on thursday in London (http://skillsmatter.com/podcast/home/agile-acceptance-testing), maybe come and let's continue the chat after the talk in the pub?

I think there is value in this but I favour the approach of getting an actual implementation of something in front of the business as quickly as possible (maybe even before the end of an iteration) and then refining our understanding based on this. This gives the business the chance to actually see something concrete and then maybe adjust their ideas of what they actually want based on this.

Maybe we can achieve this short feedback loop by incorporating both these approaches, or perhaps I'm misunderstanding the way that the Acceptance Testing 3-some would be used?

First of all, thanks for the write-up, your notes will come in very handy. Again, the key thing for me is that nothing is really carved in stone so if the things that I spoke about don't work for you, by all means modify them and use something that works.

I got a sense that we misunderstood eachother while discussing acceptance test workshops. I'm just wondering about this conclusion:

"While this idea seems good I am more of the opinion that we should just go with the acceptance tests that the QA writes, implement those, then check with the business whether everything is covered. The feedback loop in this approach is much shorter and as the key to software development for me is getting frequent feedback I prefer this approach."

Can you elaborate on that a bit more? Why do you think that the feedback loop is much shorter in this case? We all agree that a quick feedback loop is the way to go but I see it exactly opposite: if developers, business and testers do a 4hr intensive workshop on examples/tests, the feedback loop is much shorter then if you get qa to write tests, developers to implement it and then business to review it on the end of the iteration.