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:

  • 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

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.