Writing Better User Stories Through Active Acceptance Criteria
A quick tip to stronger acceptance criteria.
Acceptance Criteria. We all know it’s in our user stories, it’s what we use to drive our tests and accept functionality for our software. Recently I’ve noticed through a few coaching opportunities I’ve had, acceptance criteria is something Product Owners struggle with the most when breaking down features to stories. Here is a really quick tip I’ve picked up along the way to write better acceptance criteria.
Using an Active voice vs Passive voice
The active vs passive voice choice comes up a lot when writing scholarly work, but not often in the technical world. I think acceptance criteria is one of the places it makes sense to discuss this. All too often, I’d be reviewing a user story and the acceptance would read:
“A pop-up should be viewable on the page by the user when the cancel button is clicked”
Now, this is bad for a few reasons, but what I specifically want to break down here is the use of voice. This is written in the passive voice for a couple of reasons. First, the who, or the actor, is not emphasized. If you think about why we have user stories, they are always “As a ___”, so why would you not continue to focus on them in the acceptance criteria! Second, the action they are performing is passive using the word “should be”. I hate this approach too, acceptance criteria should be affirmative and read strongly. Here’s how I would write this acceptance:
“The user will view a pop-up when they click the cancel button”
This acceptance is now written in the active voice. Using this voice in acceptance criteria does a couple things. First, it reduces some clutter in the sentence that just makes it easier to read. If it’s easier to read it’s going to be easier for developers to find gaps, ask more questions, and write better code for the story. Next, like previously stated, it’s very clear who the actor is and what they are doing. This leads to the last point of testability, if it’s clear who is doing what in the acceptance, then it will be easier to test and pass or fail a story. Here are some more examples:
Scenario 1
Passive — When searching for an Name and receiving results, user has the ability to select a single results card
Active — The user can search for a name and select a card to view results
Scenario 2
Passive — The validation to require at least 2 alphanumeric characters in search field before search can be done by the user
Active — The user must enter at least 2 alphanumeric characters before search can be performed
In summary
- Put the actor (your user!) first in your acceptance criteria to put them in the active voice
- Make their actions affirmative, leave no room for questioning their activity
- Reduce clutter-words, make the acceptance as clear as possible
- Think about testability
- Make awesome products & have fun
