User Stories & Acceptance Criteria

1. Understanding the User Story

A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. It's a shift from writing about what the system should do to what the user wants to achieve.

To get a solid theoretical foundation, let's watch a video that breaks down the core components of a user story.

The key takeaway is the standard format:

As a <type of user>, I want <to perform some action>, so that <I can achieve some goal>.

• As a... (The Persona/Role): Who are we building this for? Being specific is better than a generic "user." For example, "As an advertiser" is better than "As a user."
• I want... (The Action/Feature): What is the goal? This should be an action they want to perform, not a technical implementation.
• So that... (The Value/Why): Why do they want this? This is the most important part, as it communicates the business value to the team and helps in prioritization.

For example, in your AdTech context:

As an ad operations manager, I want to bulk-edit the daily budget for multiple campaigns at once, so that I can save time managing large accounts.

2. What Makes a User Story "Good"? The INVEST Model

Not all user stories are created equal. A popular acronym, INVEST, provides a simple checklist to ensure your user stories are high quality.

To summarize, a good user story is:

• Independent: Can be developed and delivered on its own.
• Negotiable: It's a starting point for a conversation, not a rigid contract.
• Valuable: Delivers tangible value to the end-user or business.
• Estimable: The team can roughly estimate the effort required to implement it.
• Small: Small enough to be completed within a single sprint (development cycle).
• Testable: You can prove that it's "done."

This last point, "Testable," brings us to the final "C" of the Three Cs: Confirmation. This is achieved through Acceptance Criteria.

3. Defining "Done": Acceptance Criteria

Acceptance Criteria (AC) are the conditions that a software product must meet to be accepted by a user, a customer, or the product owner. They define the boundaries of a user story and are used to confirm when it is complete and working as intended.

Let's return to our video to get an overview of AC.

While rule-based criteria (checklists) are useful, the most powerful and widely adopted format for describing behavior is the scenario-based approach using Gherkin syntax.

4. Writing Acceptance Criteria with Gherkin

Gherkin is a simple, structured language that helps you describe a system's behavior without detailing the implementation. It is human-readable, which means you, the developers, and your stakeholders can all understand it. The core structure is Given-When-Then.

• Given: The context or precondition. What is the state of the system before the action?
• When: The action or event. What does the user do?
• Then: The expected outcome. What should the system do in response? How has the state changed?

To dive deeper into the practical application of Gherkin, let's review a dedicated guide.

Let's apply this to our AdTech example:

User Story: As an ad operations manager, I want to bulk-edit the daily budget for multiple campaigns at once, so that I can save time managing large accounts.

Here are some possible Gherkin scenarios for this story:

Scenario: Successfully applying a new budget to selected campaigns

Given I am on the 'Campaign Management' page
And I have selected three campaigns with different daily budgets
When I enter "$50" in the 'Bulk Edit Budget' field and click 'Apply'
Then the daily budget for all three selected campaigns should update to "$50"
And I should see a confirmation message: "3 campaigns updated successfully."

Scenario: Attempting to apply an invalid budget

Given I am on the 'Campaign Management' page
And I have selected two campaigns
When I enter "abc" in the 'Bulk Edit Budget' field and click 'Apply'
Then the daily budget for the selected campaigns should not change
And I should see an error message: "Invalid budget amount. Please enter a numeric value."

Notice how each scenario tests a specific piece of behavior. Together, they define what "done" means for this user story.

To see how this looks in a real-world tool, the following video segment shows user stories and Gherkin AC inside Jira, a popular project management tool.

A final tip is to keep your scenarios focused. It's better to write multiple simple scenarios than one complex one.

Conclusion

You have now learned the fundamental building block of Agile requirements documentation. By combining a clear, value-driven user story with precise, testable acceptance criteria, you provide the development team with everything they need to build the right feature, the right way. This skill directly addresses the need for formal IT documentation within a fast-moving Agile environment.

Key Takeaways:

• User stories capture requirements from an end-user's perspective using the "As a..., I want..., so that..." format.
• The INVEST model helps ensure your user stories are well-formed (Independent, Negotiable, Valuable, Estimable, Small, and Testable).
• Acceptance Criteria define the "done" state for a user story.
• Gherkin syntax (Given-When-Then) is the industry standard for writing clear, scenario-based acceptance criteria that both business and technical team members can understand.

Preview of the Next Lesson:

A single user story is great, but big projects are never just one story. They start as large ideas or features. In our next lesson, we will focus on the skill of decomposing large features (known as 'epics') into smaller, manageable user stories, ensuring that a complex business need can be delivered incrementally.