On writing good acceptance criteria for your user stories

Colorful sticky notes on a gray wall

I am a Business Analyst on an agile team. User stories and acceptance criteria are my bread-and-butter. But when I first left the comfort of elaborate requirements to embrace the simplicity of user stories, I found the concept freeing, yet challenging.

User stories were an easy concept to grasp. But understanding, internalizing and writing good acceptance criteria, which pretty much make or break your stories, made the whole thing tricky. Even now, depending on the feature I’m working on, I sometimes struggle with writing “good” acceptance criteria.

In those times, this article by Sandy Mamoli helps clear out the cobwebs.
Acceptance criteria:
  • Define the boundaries for a user story/feature
  • Help the product owner answer what they need in order for this feature to provide value (typically these are the minimum functional requirements)
  • Help the team gain a shared understanding of the story/feature
  • Help developers and testers to derive tests
  • Help developers know when to stop adding more functionality to a story