When I work as a trainer, at the beginning of the class I’m asking about my students what they expect from the course.
I write them down on a whiteboard or ask them to write them down on a post-it.
At the end of the course, we go over these and I ask everyone if they got what they wanted out of the course.
When I work as a coach, I discuss upfront with my customer what are the acceptance criteria for my position.
On one of my contracts, I did not have the acceptance criteria after 2/3 of the contract.
Instead of getting pissed of, I made me think about why I wanted AC.
As a developer I like acceptance criteria to look at what I have done and see if what I have done is what the customer wants. And I want this so that people can keep me accountable for what I did.
Can this actually be done for the work as a coach? In my experience a change agent (which I think I am as an agile coach) what I end up doing at a company is totally not the same as what we planned for. So having AC for that sounds like a contradiction. Actually it is not, I think it is the same for writing software or even creating a house. Customers don’t know what they want until they see it. That is why in an agile team we do short iterations and demo’s. So that our customers can look at what they are getting and changing the direction. We still write acceptance criteria on the stories for these iteration.
Actually the AC move the customer away from how and bring them back to the what.
When a customer asks ”make my company/team” agile. He is focusing on the how. Agile is just a means to an end.
By asking them to come up with acceptance criteria for what they want me to do I am looking for what they want.
What do you think about this?
Are you using acceptance criteria for other things then users stories and what is you experience with that?
Update: For me this is totally in sync with Begin with the end in mind from Dr Covey