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


We act as though written words are precise, yet they often aren’t. Contrast the words written on that menu with the waitress’ spoken words: “Would you like soup or salad?” Even better, she removed all ambiguity by placing a basket of bread on the table before she took my order.

Essential for Estimating
Have you ever tried to estimate or project plan from a thick, unwieldy requirements document?  You probably have and I find it to be a difficult guesstimating task.  I often take the requirements doc and break it down into bite-sized chunks just so I can estimate.  Luckily, stories naturally come in digestible units.  By breaking functionality into manageable Sprint length stories you can accurately estimate and prioritize the work.

Just Enough Detail
Details can be dangerous, especially if those details are not immediately important and might change over time.  A Sprint’s stories need details – discovered during the Sprint Planning session and subsequent Sprint.  However, stories remaining on the Product Backlog might or might not make it to the Sprint Backlog.  Save time (and angst if requirements change) by capturing the functionality wanted (i.e. the story) and defer the details until required.

For more details, see Mike Cohn’s article Advantage of User Stories for Requirements.

Traditional system-software development attempts to first document all of a product’s requirements and then freeze those requirements for the duration of the project. The assumption is we can come to a complete understanding of the product (system-software) before developing code. More often than not, dynamic business environments, incomplete project/requirements knowledge, and inherent project risk, uncertainty and complexity make static requirements impractical.  What a shame that new and possibly better ideas must be rejected because they weren’t raised during the business requirements phase.

However, Agile has a wonderful technique to overcome the requirement process limitations of traditional software development: the story.  The written words of a story and all the conversation about the story enables the Product Owner and the delivery team to effectively communicate the product features (who, wants what, why).  Requirements can and do change; the iterative nature of Agile allows the team to refocus on new or lower priority stories during every Sprint Planning session.  Thus, in agile when asked for a new feature you will never say, “I’m sorry but that wasn’t in the requirements.”

A story is a means to an end. Stories first and foremost serve as a communication mechanism leveraging effective collaboration between those who possess requisite knowledge, authority and responsibility for the requirement, the Product Owner (aka the Business or Customer) and those who possess the craftsmanship for delivering on the requirement, the development and delivery team. You will find that the more experience you have discovering and writing stories the easier it will become.

Next month, in part two, we will delve into the remainder of this answer focusing on:

  • Getting ready to write stories and eliciting requirements using stories
  • How much detail to capture
  • Writing acceptance criteria


About the Author
Russell Pannone is the founder of We Be Agile and the Agile Lean Phoenix User Group, the Agile-Lean Adoption Lead and Coach at US Airways.

With almost thirty years of system-software development and delivery experience, Russell’s focus is on working side by side with folks on real projects to help them deliver valuable system-software to production early and often. He gives those with whom he collaborates the best opportunity to beat the competition to market, realize revenue, and discover insights that can foster improvement.

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.