Writing Acceptance Criteria – For the longest time since I came into Product Management, I have struggled to write Acceptance Criteria. So what exactly made it so difficult?
Now the agile format of writing a user story goes on the lines of
As a <user profile> I want to <do what> so that I can <why >
Agile definition of acceptance criteria is the list of formal conditions that a feature must fulfil to be accepted by the user/ customer.
As a Product Owner, I have a problem-to-solution in mind which is what I want the feature to achieve. And I write this solution in acceptance criteria. Isn’t that enough? Apparently not. That way a product owner tells the developer what to develop when there might be or will definitely be better solutions for the same problem.
But then I started to realise it probably worked for a fresh product. For mature products the story (not user story , duh!) is slightly different. And with mature teams it is a different dynamic. These guys knew way more about the workings of the product and inter-twinned ball of snakes (that’s how a developer described our code). My personal experience when writing a story is I did not consider edge use cases that need to pass acceptance tests. Bugs came up! Not that bugs don’t come up with the perfect acceptance criteria.
So I took another approach for some time. I wrote the description and acceptance criteria in this format:
- What? Do we need to do
- Why? Customer need + business goal +product vision
- How? Here I explained how the feature works.
- When? I explained to my best ability the scenarios.
This approach worked well for the longest time. It still works.
Recently I read in Agile for Growth that it is a myth for Product Owner to write Acceptance criteria alone. It should be done together with the dev team. That’s true. On a requirements workshop with the customer, we started the typical discussion about the customer’s use case. But this time I tried something different. I explained my understanding of the use case and asked our UX designer to come up with a mockup in discussion with developers before the requirements workshop. Normally we do this exercise after the customer has provided inputs. With this approach, we all go to think together, developers knew exactly what part of the product we are going to discuss, we aligned on an idea and presented it to the customer. It went rather well. In the course of requirements gathering, I encouraged the developers to ask everything about edge use cases which I would never have thought about had we not done the preliminary exercise. After the workshop, I described all the scenarios we discussed in the acceptance criteria of that one story.