Preface

User Stories are a great method for expressing stakeholder requirements, whether your projects follow an Agile, Iterative, or a Waterfall methodology. They are the basis for developers to deliver a suitable information technology (IT) app or application. Well-structured user stories express a single action to achieve a specific goal from the perspective of a single role. When writing user stories, stakeholders knowledgeable about the role should focus on the business result that the IT solution will enable while leaving technology decisions up to the developers. Good user stories are relevant to the project, unambiguous, and understandable to knowledge peers. The best user stories also contain crucial non-functional (quality) requirements, which are the best weapon in the war against unsatisfactory performance in IT solutions.

This book presents two common user story structures to help you ensure that your user stories have all the required components and that they express the true business need as succinctly as possible. It offers five simple rules to ensure that your user stories are the best that they can be. That, in turn, will reduce the amount of time needed in user story elaboration and discussion with the development team.

This book targets business professionals who are involved with an IT project, Product Owners in charge of managing a backlog, or Business Analysts working with an Agile team.

Author’s Note

The term “User Story” is a relative new addition to our language and its definition is evolving. In today’s parlance, a complete User Story has three primary components, namely the “Card”, the “Conversation”, and the “Criteria”. Different roles are responsible for creating each component. The “Card” expresses a business need. A representative of the business community is responsible for expressing the business need. Historically (and for practical reasons) the “Card” is the User Story from the perspective of the business community. Since we wrote this book specifically to address that audience, we use the term “User Story” in that context throughout.

The “Conversation” is an ongoing discussion between a developer responsible for creating software that meets the business need and the domain expert(s) who defined it (e.g., the original author of the “Card”). The developer initiates the “Conversation” with the domain expert(s) to define the “Criteria” and any additional information the developer needs to create the application. There is much to be written about both the “Conversation” and the “Criteria”, but neither component is dealt with in any detail in this publication.

A well-written User Story (“Card”) can drastically reduce the time needed for the “Conversation”. It reduces misinterpretations, misunderstandings, and false starts, thereby paving the way for faster delivery of working software. We chose to limit the content of this publication to the “User Story” as understood by the business community to keep the book focused and address the widest possible audience.

Meanwhile, please enjoy this book. We appreciate any comments, suggestions, recommended improvements, or complaints that you care to share with us. You can reach us via email at books@businessanalysisexperts.com.

Audience

This eWorkbook will help anyone tasked with capturing, writing, analyzing, or understanding the requirements for Information Technology projects, in particular:

Business Analysts

Subject Matter Experts (SMEs)

Product Owners and Managers

Project Managers

IT Developers

Software Testers

Anyone wearing the Business Analysis hat

Table of Contents

Contents

Preface

About the Authors

Business Analysis Using User Stories

Keep Your User Story Simple

Express the What, Not the How

Write Relevant User Stories

Avoid Ambiguity in Your User Story

Measurable Non-Functional Requirements

Rules Review

Additional information

About the authors

Angela and Tom Hathaway have authored and delivered hundreds of training courses and publications for business analysts around the world. They have facilitated hundreds of requirements discovery sessions for information technology projects under a variety of acronyms (JAD, ASAP, JADr, JRP, etc.).
Based on their personal journey and experiences reported by their students, they recognized how much anyone can benefit from a basic understanding of what is currently called “business analysis”. Their mission is to allow everyone, anywhere access to simple, easy-to-learn techniques by sharing their experience and expertise in their training seminars, blogs, books, and public presentations.

Requirements ARE Our Business! A video about BA-EXPERTS

Reviews

There are no reviews yet.

Be the first to review “Book: Writing Effective User Stories” Cancel reply

Your email address will not be published. Required fields are marked *