If you are sitting down to write user stories and acceptance criteria for an upcoming sprint, the format is the easy part. The hard part is making sure what you write actually communicates the business need clearly enough that a developer can build it and a tester can verify it without coming back to you three times. I have spent a long time learning that distinction the hard way, and this article is about helping you get it right before the sprint starts rather than patching it up during one.
Knowing how to write user stories and acceptance criteria means understanding both the available formats and the principles that determine whether those formats are serving you or just filling space on a ticket. Let me work through both.
The Standard User Story Format
Most BAs are familiar with the three-part structure: As a [role], I want to [action] so that [outcome]. This keeps the focus on the end user’s goal and the value the story delivers, rather than on system behaviour or technical implementation. Its simplicity is deliberate. It forces you to be clear about who needs what and why, which is genuinely useful discipline, especially when stakeholders are inclined to describe solutions rather than needs.
What the format does not do is tell you how detailed the acceptance criteria need to be, when supplementary artefacts are required, or how to handle requirements that do not have a user at their centre. Those are the questions that separate a workable story from a vague one.
Writing Acceptance Criteria: Given-When-Then
The most widely used format for acceptance criteria is Given-When-Then (GWT), sometimes called Gherkin format. The structure is: Given [a condition or context], when [an action occurs], then [the expected outcome].
For example: Given that I am a registered user, when I submit the application form, then the system saves the record and displays a confirmation message.
GWT works well because it tells the requirement as a scenario grounded in context and user intent. It is readable by both business stakeholders and developers, which makes it a reliable communication tool across the team. When the “then” clause needs to cover detailed system behaviour, field-level rules, or specific page elements, one practical approach is to list those details as bullet points beneath the GWT statement. This keeps the scenario readable at a glance while still capturing the specifics that developers and testers need. The drawback is that tickets can become long and harder to consume quickly.
An alternative is to pull that level of detail out of the story entirely and capture it in wireframes or supplementary annotations, keeping the story itself clean. Neither approach is wrong. The right choice depends on what communicates most effectively for your team.
When Plain Requirement Statements Work Better
GWT is not the only valid format for acceptance criteria. Writing acceptance criteria as plain requirement statements works perfectly well in many contexts, particularly for conditions that do not map naturally to a user-facing scenario. There is no industry rule that mandates GWT for every story. What matters is that the acceptance criteria clearly communicate the conditions, rules, and boundaries for the story in whatever format achieves that most effectively.
The FDD Format for Non-User-Facing Requirements
For requirements that sit a step back from the user, such as non-functional requirements, system constraints, or background processing rules, the Feature Driven Development (FDD) syntax is worth knowing: [action] the [result] [by/for/of/to] a(n) [object].
For example: Generate a unique eight-digit identifier for the application record.
This format handles the types of requirements that feel awkward and forced when written as user stories. Not every requirement has a user role at its centre, and trying to fit system-level or non-functional requirements into the story format often produces something unclear. The FDD syntax is a cleaner fit for those cases. If you work with non-functional requirements regularly, the article on how to write requirements that are not user-facing covers this territory in more depth.
Format Comparison: When to Use Each Approach
| Requirement Type | Recommended Format | Why It Works |
|---|---|---|
| User-facing feature with a clear scenario | Given-When-Then (GWT) | Scenario-based, readable by business and technical team alike |
| Simple condition or rule without a scenario flow | Plain requirement statement | Cleaner and faster to write and read when no scenario context is needed |
| System-level, background, or non-functional requirement | FDD syntax | Avoids forcing a user role where none naturally exists |
| UI-heavy feature with field-level detail | GWT plus wireframe annotations | Keeps the story readable while capturing visual and field-level specifics |
A Worked Example: Where It Got Complicated
On Project X, a public sector case management system, I was writing stories for an online application journey. The product owner and I had agreed on GWT for all user-facing stories and plain statements for system-level rules. That held up well until we reached the identity verification step, which had significant conditional logic depending on the type of applicant.
The development team lead pushed back on the stories I had written for that step. His view was that the acceptance criteria were too high-level to build against. He wanted field-level validation rules, error message text, and retry logic all captured inside the ticket. I understood his concern, the team had been burned before by ambiguous criteria that produced a build the testers could not sign off on. But I had deliberately kept the stories concise and planned to capture that detail in wireframes and a supplementary data dictionary.
We had not agreed on this approach as a team upfront, and that was the real problem. I had assumed the wireframes would carry the field-level detail. The development lead had assumed the ticket would be self-contained. Neither of us was wrong about what we needed; we had just never had the conversation about where the information would live.
We resolved it by running a short team session to agree a definition of ready: what information was required on every ticket, what could live in linked wireframes, and what needed to be in the acceptance criteria directly. For the identity verification stories specifically, we added a second acceptance criteria block below the GWT statement that listed the conditional rules in plain statements. It added length to those tickets, but it removed the ambiguity, and the development lead signed off on the next refinement without issue. The sprint ran cleanly. The session we should have had at the start of the project took forty minutes and saved considerably more time than that across the remaining sprints.
The Principles That Matter More Than the Format
- The story clearly represents the business requirement and the user’s goal. A well-written story communicates the business need in terms that a subject matter expert can validate and a developer can act on. If it does not do both, it needs more work.
- The acceptance criteria clearly define the conditions for passing. Vague acceptance criteria are one of the most common causes of rework in Agile delivery. If the conditions for passing are ambiguous, different people will interpret them differently, and the build will reflect those differences.
- The team has agreed on what information is required for each ticket. This includes the format of the story, the depth of the acceptance criteria, and any supplementary material such as wireframes, data flows, or process diagrams. Agreement upfront eliminates a significant amount of uncertainty during sprint work.
- The team has agreed on when information needs to be available. Development and testing can only proceed effectively when the information they need is ready at the right time. Establishing clear expectations about when stories need to be elaborated prevents bottlenecks in delivery.
- The whole team contributes to elaboration. One of the underlying principles of Agile delivery is that developers can help elaborate requirements and BAs can contribute to functional testing. The traditional boundaries between roles are more fluid than in a plan-driven environment, and good story writing benefits from that.
Wireframes as a Complement to Stories
Simple wireframes are a valuable companion to user stories, particularly for interface-heavy requirements. They do not need to be polished design artefacts. A basic sketch that shows the layout, the key elements, and how they relate to each other is enough to communicate what the story describes. Tools like Figma, Balsamiq, and Miro all work for this purpose, as does a simple drawing tool if that is what your team has available.
Wireframes are especially useful for pulling visual and field-level detail out of the story itself, keeping the story readable while still capturing the specifics the team needs. If you are working in an environment where the BA is also expected to produce process documentation alongside stories, the business process documentation template is worth having alongside your story template.
Agile Principles and Practical Adaptation
Agile methodology provides principles, not prescriptions. There is industry best practice, and there is good practice that fits your organisation. Knowing the fundamental principles before you adapt them is important: it means your adaptations are deliberate and grounded, rather than accidental departures from a standard you never fully understood. If you want a broader grounding in how the BA role sits within an Agile team, the article on the Agile business analyst covers the role and its boundaries in practical terms.
The goal is a shared agreement within your team on what good looks like: stories that communicate the business requirement clearly, acceptance criteria that define success without ambiguity, and a consistent approach that everyone understands and trusts. Getting that agreement on paper, even as a simple one-page definition of ready, is one of the most productive things you can do before a project picks up pace. The format you choose for your stories matters far less than the clarity of the conversation that produces them and the shared understanding that surrounds them.
Frequently asked questions
What is the correct format for user stories in Agile?
The standard format is: As a [role], I want to [action] so that [outcome]. This keeps the focus on the user’s goal and the value the story delivers rather than on technical implementation. It is widely used because it is simple and forces clarity about who needs what and why.
What is the Given-When-Then format for acceptance criteria?
Given-When-Then (GWT) structures acceptance criteria as a scenario: Given [a condition or context], when [an action occurs], then [the expected outcome]. It works well for user-facing features because it is readable by both business stakeholders and developers. It is not mandatory, and plain requirement statements are equally valid when a scenario structure does not fit the requirement.
How detailed should acceptance criteria be?
Detailed enough that a developer knows exactly what to build and a tester knows exactly what to verify without needing to ask for clarification. The practical test is whether someone unfamiliar with the background conversation can read the acceptance criteria and know unambiguously whether a build passes or fails. If the criteria are open to interpretation, they need more work.
How do you write acceptance criteria for non-functional requirements?
Non-functional requirements rarely fit naturally into the user story format, and forcing them into it tends to produce something awkward. The FDD syntax, structured as [action] the [result] [by/for/of/to] a(n) [object], is a cleaner fit for system-level and non-functional requirements. Alternatively, they can be captured as separate backlog items with their own plain-statement acceptance criteria.
How do you get team agreement on user story format and depth?
Raise it explicitly in a team session rather than letting it emerge organically from sprint work. Agreeing on what information is required for each ticket, what format it takes, and when it needs to be ready is a foundational conversation that pays dividends across the life of the project. A simple one-page definition of ready is enough to create the shared understanding the team needs.
Try Ash, Your Virtual BA
If you are working through a backlog right now, Ash Virtual BA can help you write user stories and acceptance criteria that are complete, unambiguous, and ready for development. Ash works through your requirements systematically, covering functional requirements, acceptance conditions, non-functional requirements, and the detail that stops stories from coming back to you during a sprint. If you are working from a brief or scope document, Ash reads it, pre-fills what it can, and focuses its questions on what is genuinely missing. Try Ash Virtual BA and see how much faster your next refinement session can go.
Further reading
- User Story – at business rule / field validation level. | Scrum.org
- Should every user story have an acceptance criteria? | Scrum.org
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.