I have a love/hate relationship with acceptance criteria written with the “Given, When, Then” format . It’s not a recent feeling either, it has been something that has bugged me since I started working with teams that write user stories. I’m not “anti” this format but I am “anti” using it as the only format for stating ways in which software might be acceptable to clients.
I’ve mentioned in previous posts that I’m lucky to work with a team of people that are open to experimenting with ideas. They will happily try new ideas and provide honest feedback on how well they felt the experiment progressed, whether it provided value in their opinion. As a team we have learnt how to listen, experiment and respectfully challenge other views with the aim of improving what we do as a team. As the specialist tester on the team it would be fair to say I exploit this ethos, with only good intentions, of course.
Recently I attended CAST X18 in Melbourne and participated in Paul Hollands workshop – “Creativity, Imagination and Creating Better Test Ideas”. I don’t plan to describe the workshop other than to say it was a lot of fun (Paul has a great sense of humour) and I took away a few useful ideas. Among these was trying to develop test ideas, or test scenarios, before you develop any real depth of detail on a story. In short, detail can really strangle creativity.
Not long after the conference I was sitting in a grooming session. There was a lot of talk about the acceptance criteria, largely circling around rather than progressing forward. I asked the team if we could, instead of defining the acceptance criteria, capture test ideas that we would explore and other “knowns” we could check for regression. I suggested that if we could grab test ideas we could then circle back and think about acceptance criteria with a different perspective. It didn’t take a lot of chat to get this going and everyone chipped in with really good ideas. We never did circle back to the acceptance criteria. Everyone felt that we had captured what we needed with the test ideas.
The above story is not the first time that we have had problems with acceptance criteria or the first time we have chosen another path. I largely blame the language of the “Given, When, Then” format. Seems to me it is the “go to” option rather than a “possible” option. In my opinion that format is not representative of natural language (do you speak like that in everyday communication?) and it stifles creativity as people try to manipulate meaning into it. I’ve see plenty of instances where it seemed that producing something in “Given, When, Then” appeared to be the goal, an item to be ticked off as done, even if the end result was a bland statement that did not provide guidance on what a user values.
In previous stories where we have been unable to craft meaningful acceptance criteria we have resorted to bullet pointing criteria. In each instance that I can remember, moving away from the rigid “Given, When, Then” format has enabled the team to produce and capture useful statements about value in the story. Further, when we have done this our thinking has been wider and deeper (which anecdotally supports the lesson I mentioned earlier from Paul Holland’s workshop).
Recently I stumbled across an article by Mike Cohn about conditions of satisfaction
“….conditions of satisfaction are specific to a given product backlog item and define what must be true for that product backlog item to be considered done. For example, a user story such as, “As a user, I am required to login before using the site,” might include these conditions of satisfaction:
user is logged in only when proper credentials are provided
- a “remember me” option is available
- user can request a password reminder
- user is locked out after three failed attempts
In my opinion, conditions of satisfaction, or a similar approach, represent a much simpler way of capturing the essence of acceptance and creating conversations about considerations beyond the acceptance. Should we not also gather thoughts on:
- behaviour that would make the software entirely unacceptable
- other areas impacted by this change
I guess there is an argument that details will fall out as we develop the story and discuss findings. I have a small problem here. It assumes that good conversations will take place and the people involved will recognise the problems as they go. That’s a mighty big assumption. If we have thoughts during grooming about ways the software might regress or become unacceptable, let’s capture those, in the moment, and take that knowledge into our subsequent development activities. Having this already captured frees up mental space for us to look for other problems during development, other deeper, more subtle ways in which the software might not be acceptable.
I dare say there are a bunch of people who have been involved in developing user stories for a long time and are doing the above, or even more. There are possibly also a lot of good practitioners that can manipulate every “Given, When, Then” into valuable statements. My personal experience however is that there are still a lot of people who hold fast to “Given, When, Then” as the only way to write acceptance criteria and find it problematic (it’s a reasonably frequent topic on LinkedIn). The user story exists as a vehicle for us to have conversations, and initiate actions, that enable delivery of software that allow our clients to meet their business goals. The we go about this should not be copy and paste but thoughtful and appropriate. My suggestion, abandon that thinking and experiment. Find good ways to capture information that supports the team delivering high quality software efficiently and use each as dictated by context.
@Beaglesays 
2 thoughts on “Given, When, Then….Mental Indigestion”