How Do I Write Requirements Using Stories and Acceptance Criteria?—Part One


What is a Story?

Stories form the bedrock for communicating agile product development requirements. A story is a central part of the iterative and incremental development and delivery of commercial or operational value.  A story makes possible delivering value early and often by focusing on effectively communicating the underlying business requirement and value instead of the delivery mechanism.

Ron Jeffries, one of the creators of Extreme Programming (XP), described what has become the de-facto standard way to think about stories. Ron used the alliteration of card, conversation, and confirmation to describe the three elements of a story[1]:

  • Card - represents the two to three sentences used to describe the intent of the Story.
  • Conversation - represents fleshing out the details of the intent of the card in a conversation with the customer or Product Owner.
  • Confirmation - represents how the team, via the customer or customer proxy, comes to verify that the code meets the full intent of the Story.

A good story is negotiable, testable, possible to estimate, commercially or operationally value adding, cohesive, and loosely coupled.  It is not an explicit contract for features or functionality.

A Story is:

  • “A simple, clear, and brief description of functionality told from the perspective of a user [e.g. Product Owner]” (Cohn, 2010).
  • Aligned against a business value.
  • Refined in successive conversations between the Product Owner and the Development Team.
  • Leverages effective collaboration between those who possess requisite knowledge, authority, and responsibility for the requirement, the Business or Customer, and those who possess the craftsmanship for delivering on the requirement, the Development Team, resulting in commercial or operation value.

But Why Stories?
You may be asking, “Aren’t stories just use cases or requirement statements?”  While overlapping features exist, all three have distinct structures and goals.  Stories encapsulate discreet units of functionality with the longevity of a single iteration/sprint.  On the other hand, use cases contain larger units of work composed of many stories and typically last longer than a single iteration/sprint.  Requirement statements go a step further by documenting every requirement in the minutest detail – ever had a 200+ page requirements document?

Mike Cohn, one of the most distinguished Agile authors, describes three main advantages of stories:

Verbal Communication
Which do you think is more precise, verbal or written communication?  The best form of communication depends upon the context and purpose of the message.  If you can detail all aspects of the requirements in clear and precise language, removing all misconceptions on the part of the reader, please write detailed requirements.  However, if you believe understanding and clarity comes from questions, feedbacks, and non-verbal communication cues, look to create stories.

Cohn gives a wonderful example of the imprecision of written communication:

At lunch recently I read this on my menu: “Entrée comes with choice of soup or salad and bread.”  That should not have been a difficult sentence to understand, but it was. Which of these did it mean I could choose?

  • Soup or (salad and bread)
  • (Soup or salad) and bread

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!