The fourth installment of my blog series on “20 Controversial Topics of Debate in Agile” is about the best way to write Acceptance Criteria. If you’re reading this, I assume you know what Acceptance Criteria are. The scope of this blog is simply the format they take.
What formats can Acceptance Criteria take?
List-style Acceptance Criteria
List-style Acceptance Criteria is the most common Acceptance Criteria format, but that doesn’t necessarily mean it’s the best. I use this style when it’s preferred (or dictated) by my audience (a.k.a. my developers). This choice is often made because the developers either:
- Are super senior and don’t need/want much in the way of details to develop a solution, OR
- They don’t like to read a lot of words
Example:
- An error message displays if mandatory fields are not completed
- Form information is stored in the database
- Payment can be made via credit card (Visa, MasterCard, Discover, AmEx)
- If anything goes wrong, the user will see a message indicating what is wrong
- After submitting the form, an acknowledgment message is provided
List-style Acceptance Criteria Pros and Cons
Pros
- Quick and dirty
- Fewer words to read
- Each item can be pass/fail
- Can be used as a test case
- Easy to understand
- Leaves room for developer creativity
- Contains “just enough” information
Cons
- Not methodical
- It’s easy to miss things
- Doesn’t help discover gaps
- Usually ignores negative cases
- Can be misunderstood
- May not have enough detail
- Story boundaries may not be clear
Scenario-style Acceptance Criteria
Scenario-style Acceptance Criteria focus on the different paths a user can take to navigate the functionality of the story. This format reminds me of old-style Use Cases but in a slightly less formal manner. The key is to cover all the happy, unhappy, exception, and alternative paths so you don’t have any gaps.
Example:
Happy Path:
- User can check out without any errors
- User receives a confirmation after checkout
- Order is successfully transmitted for fulfillment
Unhappy Path:
- User receives an error and cannot proceed if required fields are empty
- User cannot proceed until the required fields are populated
Exception Path:
- Data validation on a field failed
- Field with error is highlighted and the specific problem identified
- User can correct the error
Alternative Path:
- User can return to shopping if not ready to check out
- Items in the cart will be saved
Scenario-style Pros and Cons:
Pros
- More methodical than list-style
- Ensures negative options are considered
- The format is consistent and predictable
- Can aid in writing structured test cases
Cons
- Includes more words to read
- Isn’t succinct; more narrative
- Can take time to understand
- It’s somewhat prescriptive
Behavior-Driven Development-style Acceptance Criteria
This type of Acceptance Criteria is one of my favorites, but it requires extra work. Behavior-driven Development (or BDD) uses a specific format that easily translates into test cases or even test automation using Gherkin. This approach is like scenario-style but is more structured and also has aspects of Use Cases. The format is:
Given: (pre-conditions)
When: (trigger)
Then: (post-conditions)
Example:
Given:
- I ‘m a logged-in user
- My account is active
- I have added items to my cart
When:
- I proceed to checkout
Then:
- My information is pre-populated
- Previously saved payment options are available
- Items in my cart with prices are displayed, along with a total
- I see an option to enter a promo code
Behavior-driven Development-style Pros and Cons
Pros
- Very logical and methodical
- Ensures all scenarios are covered
- Testable by design
- Can be used to create automated tests
- Includes pre- and post-conditions
- The format is consistent and predictable
- Can cover multiple scenarios
Cons
- Takes a lot longer to write
- A lot of reading is required for developers
- Doesn’t leave a lot of developer flexibility
- It may be overkill, depending on the situation
- Can become overly complex
Tabular-style Acceptance Criteria
Acceptance Criteria in tabular format are useful when there’s a lot of data that needs to be validated. It’s also appropriate for rule-based Acceptance Criteria and helps automate decision-making based on a set of pre-defined rules.
Example:
| Condition | Case 1 | Case 2 | Case 3 | Case 4 | Case 5 |
| Customer has an account | Y | Y | Y | Y | N |
| Customer is logged in | Y | Y | Y | N | N |
| All required fields are populated | Y | Y | N | N | N |
| Payment method is available | Y | N | N | N | N |
| Can customer check out? | Y | N | N | N | N |
Pros and Cons of Tabular-style Acceptance Criteria
Pros
- Very structured
- Makes complex options simpler
- Works well with lots of data
- Fewer words to read
- Helps ensure full test coverage
Cons
- Can be overwhelming
- It may still be too complex
- Does not provide as much context
What do you think?
So, now that you know about different ways to write Acceptance Criteria, which style do you think is the best? Are there any other methods of documenting Acceptance Criteria that you have used? Let me know in the comments area below!
And up next in this blog series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can agile co-exist with waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?