The JIRA ticket looked perfect. You’d spent an hour crafting the user story, channeling the customer’s voice, their hopes, their dreams for a better checkout experience. "As a shopper," you wrote, "I want to apply a discount code so I can save money." You felt the empathy radiating from the screen. You attached the Figma link, tagged the engineer, and moved on to your next meeting.
Then came the Slack DMs.
"What happens if the code is expired?" "What's the error message for an invalid code?" "Should the button be disabled if the input is empty?" "What if they try to apply two codes?"
Suddenly, your user story—a beautiful expression of why—was collapsing under a pile of tactical what-ifs. You became a real-time spec-writer in a Slack thread, and the sprint work ground to a halt waiting for your answers.
Your user story wasn't wrong; it was just incomplete. A user story is a promise. It aligns the team on a user-centric goal. But an engineer can't build a promise. They build logic, states, and conditions. They need a contract.
That contract is called acceptance criteria.
From Aspirational to Actionable
A user story is the start of the conversation. Acceptance criteria (AC) are the documented conclusion of that conversation. They translate the user’s goal into a testable set of outcomes. They are the definition of done, written before a single line of code is.
Writing good AC isn't about listing every technical detail. It's about thinking through the problem like an engineer and a QA tester. It’s about defining the boundaries of the feature so your engineering team can build with autonomy and confidence.
The simplest, most effective format for this is the Gherkin syntax: Given, When, Then.
- Given: The setup. The initial context before the action happens.
- When: The specific action the user performs.
- Then: The expected result. The observable outcome of the action.
This structure forces you to be precise. It moves the ambiguity out of the narrative and into a clear, cause-and-effect statement.
A Tale of Two Tickets
Let's look at that discount code feature again.
The "Before" Ticket (User Story Only):
Title: Add Discount Code to Checkout
User Story: As a shopper, I want to apply a discount code to my cart so that I can save money on my purchase.
Designs: [link_to_figma.com]
This is a wish. It invites questions and assumptions.
The "After" Ticket (User Story + Acceptance Criteria):
Title: Add Discount Code to Checkout
User Story: As a shopper, I want to apply a discount code to my cart so that I can save money on my purchase.
Designs: [link_to_figma.com]
Acceptance Criteria:
Scenario 1: Successful Application
- Given I am a logged-in user on the cart page
- And I have at least one item in my cart
- When I enter a valid coupon code "SAVE10" into the coupon field
- And I click the "Apply" button
- Then the cart subtotal is reduced by 10%
- And I see a success message: "SAVE10 applied!"
Scenario 2: Invalid Code
- Given I am on the cart page
- When I enter an invalid code "INVALID"
- And I click "Apply"
- Then I see an error message below the field: "This coupon code is not valid."
- And the cart total does not change.
Scenario 3: Empty Input
- Given I am on the cart page
- When I click "Apply" while the coupon field is empty
- Then the input field border turns red
- And a message appears: "Please enter a code."
Scenario 4: Expired Code
- Given I am on the cart page
- When I enter an expired code "OLDNEWS"
- And I click "Apply"
- Then I see an error message: "This coupon has expired."
This is a contract.
The second ticket preempts the Slack questions. It defines the happy path, the error states, and the edge cases. An engineer can read this and know exactly what to build. A QA tester can read this and know exactly what to test. You, the product manager, have done the hard work of thinking through the details upfront.
Stop writing tickets that are just the beginning of a conversation. Spend the extra 20 minutes to define the happy paths, the sad paths, and the edge cases. You’re not just writing down requirements; you’re building clarity and buying back hours of your team’s time. The user story sets the vision. The acceptance criteria make it real.
Generated by Reportify AI — Automate your team's status reports, standups, and weekly updates. Try free →