Acceptance criteria [AC] gives a team of developers a very simple possibility to verify whether a user story was resolved correctly. That is the case when in the sprint review the developers present to the Product Owner [PO] the software that he had in mind originally: “works as intended” instead of “works as coded”!

If he only knew what he wants! – you might say as a developer.

Well that´s part of the challenge or even the reason why in the past my software sometimes has been a surprise to the PO; not a good surprise though. That’s the main point about it. The thing that the PO wished for and expressed in a user story was not the same thing that I understood from it. And that´s why acceptance criteria are necessary, because it helps to draw the overall picture. Even more it forces the team to talk about the PO´s expectations.

There are plenty of sites and blogs out there that address this topic. I’m not writing this thinking there´s too little information available. Rather, I want to share my experience with it and lay out our approach to find proper AC.

„We know what the user want…“

I think one common misunderstanding about AC is that it’s the PO´s responsibility to fill out the AC´s field in the user story; because he´s the one who should know what he wants, right?
But, at the end of the sprint all developers will be VERY thankful if there are AC that they can check their software against. Therefore the developers should have great interest in finding them in the beginning of the sprint. Clearly this is a team task. Discussing the content of the user story as a team can be the best inspiration to come up with good ACs. They can be proposed by anyone from the team as well as the PO.

In the past the field for the AC mostly was left empty during the whole sprint. Reasons for that have been:

• “We all know what the PO wants, therefore we do not need it…”
• “I can’t think of any good ACs here….”
• “Let´s save us time and skip that!”

Skipping the ACs never was a good idea and we always paid for it in the end. Because sometimes it might really feel unnecessary to talk about it. I found help once in an article that introduced an interviewing technique that can help when the conversation between developers and PO won’t emerge really. It can be found here (in German language though). Basically you use a list of question words to highlight different angles and aspects of the topic.

Having this list is a good helper to not overlook something and as I said before it fuels the conversation.

What I have experienced in almost every discussion over a user story is that finding the AC will lead to someone say something like: ‘Oh! That part I did not see so far’ or ‘I didn’t know it was meant like that…’! Talking about AC not only helps at the end of the sprint. Furthermore it clarifies and helps gaining a common understanding of the topic before you start implementing.