A common way of developing software is to use acceptance criteria for tasks or user stories. When things are simple, it works fine. But with more complex tasks it tends to break down from time to time. Especially when dealing with moving data between different services.
However, both PMs and developers tend to take the short route and end up with a bunch of bugs. A small change in thinking is required to get it right.
Let’s say we want to start sending out messages to new users via Intercom. See if you can spot a difference between these two acceptance criteria:
- When a new user gets invited, send an invite event to Intercom
- When a new user gets invited, an invite event is present in Intercom
Seems like the same thing, right? It isn’t.
I can’t count how many times ACs like this have ended up with having to fix bugs either immediately afterward or discovering them weeks later.
What tends to happen in the first case is that developers write code for sending events to Intercom when users are invited but they don’t necessarily check whether it actually arrives in Intercom. A response code might say that everything is okay although, for example, the user and company IDs were mixed up. Everyone tries to take shortcuts when they can. Especially when deadlines are tight, and the pressure is on.
The key to the second acceptance criteria is that it also contains a way to check whether the AC has been met. It forces developers to make sure that they implemented the solution correctly— “an invite event is present in Intercom” doesn’t just mean writing a bunch of code that doesn’t return an error response; it means that they will have to check whether the event is actually attached to the specific user in Intercom.
Sometimes, the devil is in the details.