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


Russell Pannone writes that knowing what comes before the writing of stories, what comes after the writing of stories, and who is going to consume the stories sets the context for the form and substance of a story.

This is part one of a two-part article excerpted from a book I am writing to be published by Addison-Wesley. The book will be the first book to provide agile-lean product development practitioners with a pragmatic, clear, and concise collection of answers to your questions about agile and lean product (system-software) development.

I imagined a user grabbing another user in the hallway and saying, ‘I gotta tell you about this wonderful new thing the application does… ’ Stories are the Stories customers wish they could tell about the system but can’t (yet).”

– Kent Beck

How do you define your project and business requirements?  Do you use the classic method of creating a Business Requirements Document (BRD) early in the project regardless of the project length?  How has that worked for you, especially on a 6-month or year-long project?  Did you need BRD change requests during the project because the team discovered new information, market conditions changed, or someone had an even better idea?  Agile has a different take on the concept of requirements.  Instead of presciently scribing the exact requirements for the project, and compensating for all eventualities, Agile recommends creating a vision of the product, succinct bite-size statements of business value from the Customer’s or Business Partner’s point-of-view, and criteria to verify the delivery completeness; or in Agile terminology, a Product Vision, Stories, and Acceptance Criteria.

Knowing what comes before the writing of stories, what comes after the writing of stories, and who is going to consume the stories sets the context for the form and substance of a story. 

The Tie between Writing Agile Requirements using Stories, the Product Vision and an Agile Requirements Positioning Statement
"If you don't know where you are going, that's where you'll end up.”

-Yogi Berra

A Product Vision and an Agile Requirements Positioning Statement should exist prior to writing agile requirements using stories.  The product vision forms the bedrock for writing agile requirements using stories, and drives the iterative and incremental delivery of commercial or operational value.

One of the key characteristics of the product vision is its focus on describing commercial or operational business value instead of the mechanics of how that value is delivered. An agile-lean product development and delivery team divorced from context can produce very erratic and unpredictable results. The product vision serves as a mechanism to provide context and as a result ground the product development effort in reality. The details of why the Product Vision is important when writing agile requirements using stories is another question and answer that will be included in my upcoming book.

The Agile Requirements Positioning Statement defines the need, belief, and the readiness of the individual, team and organization to do what it takes to effectively elicit and write agile requirements and in turn deliver commercial or operational value. The Agile Requirements Positioning Statement ensures unanimity of purpose within the enterprise and the agile product development and delivery teams by serving as a reference point, educational value, and motivating force:

Reference Point
It guides by providing a common understanding of purpose between the business and the product development team.

Educational Value
It educates people about the common goals and objectives for writing agile requirements. When everyone is able to understand the overall approach a kind of unity of purpose is achieved.

Motivating Force
It offers a roadmap to all team members. They draw meaning and direction from it. Targets are set, work is committed to and team members can now compare themselves against the benchmark set by the agile-lean requirements positioning statement. They can unilaterally change direction whenever they go off the track and set everything along right paths.

Here is an example of an agile requirements positioning statement:

Agile Requirements Positioning Statement


  1. System-software development can only deliver what people ask for and what the developers understood the request to mean; which in the end, more often than not, does not deliver what the people really wanted.
  2. The traditional approach is to attempt to document the requirements for the whole product and then freeze the requirements to provide a stable base for development to proceed. The assumption is we can come to a complete understanding of the product (system-software) before developing code. This is a risky assumption to make for most system-software products high in risk, uncertainty and complexity.

Tenets - Guiding Principles

  1. We recognize and acknowledge the final product evolves during its development and we must positioning ourselves to adapt to change
  2. We realize trying to document all requirements and freezing requirements during early project phases will either cause rework or the delivery of a product that does not meet the Customer needs.
  3. The minimum key Agile requirement artifacts are a Product Vision,  Stories and a prioritized and sized Product Backlog; managed and owned by the Business Partner or Customer.

Enactment – Make it So

  1. Fundamentally, our approach is building product features iteratively and incrementally by Business Partners and IT working collaboratively; built around a key assumption – we continue to learn about the product during the project.
  2. Leveraging effective collaboration between who possess requisite knowledge, authority and responsibility for the requirements, the Business Partner, and who possess the craftsmanship for delivering on the requirements, the Development Team.

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.