How to Write Clear User Stories

One of the foundational skills that a Business Analyst must have is understanding stakeholders requirements, and documenting those requirements for the team in clear and concise user stories.  Clear user stories require fewer review cycles to confirm and validate, and are easier for developers to build and for the testers to evaluate.

Though there's no one-size-fits-all approach to writing clear user stories, there are varying schools of thought on what constitutes a good requirement statement.

Abiding by certain recommended structure will improve the clarity of user stories.

Ideally, every requirement statement should contain:

• A user role that benefits from the requirement
• A desirable state that the user role wants to achieve
• A metric that allows the requirement to be tested, where applicable

In addition to the challenge of ensuring that each requirement statement abides by the above structure, here are a few tips on how to achieve clear and complete user stories.

1. Each user story must define one requirement at a time. Complex requirements must be broken into smaller user stories, so that each one can be considered a discrete test case.
2. A user story must be measurable and specific, meaning it must be possible to clearly tell when this requirement has been met. Defining clear Acceptance Criteria for a story helps ensuring measurability.
3. User stories must avoid describing “how” the system will do something. Only “what” the system will do must be described.
4. A user story must refrain from explaining system design. Specification of field names, data models, and software objects in the story must be avoided.
5. Ambiguous terms such as best practices, versatile, robust, minimal, etc. must be avoided, as these make it difficult to define test cases for the story.
6. User stories must be self-sufficient and provide clear links to all references made in the story with no cross referencing.
7. Duplication and contradictory statements must be avoided
8. Ideally, user stories must be written once all requirements are clearly defined. Reference to a requirement that is yet to be defined or is pending decisions must be avoided
9. Positive statements are preferred to negative statements; e.g., “The system should…”, instead of “The system should not...”.

Of course, there is much more to say about user stories, but these overall points are a great starting point, and always good to use as a guide.