Bridging the Gap: Crafting Effective User Stories to align business vision and user expectations

Drawing from my experience with agile methodologies like SAFe and Scrum, I have seen firsthand how well-defined user stories can bridge the gap between a company’s long-term vision and user expectations. In this third article, we will delve into the importance of user stories and acceptance criteria. We’ll explore how to structure an effective user story, from identifying user needs to defining acceptance criteria, using techniques such as BDD and the INVEST acronym.

What are User Stories?

According to the book "Product Backlog Building" by Fábio Aguiar, a user story is a description of a need from the perspective of the user or customer. Mike Cohn also emphasizes the importance of understanding these needs to develop solutions that truly provide value.

Example of a User Story:

Receive a discount

Receive a payment confirmation email with Pix

View the receipt on screen after payment with Pix

Access the payment receipt in my web account

Make a payment via Pix to get a discount

Structure of User Stories

To write an effective user story, it is essential to answer three questions:

• Who? - Who is the user that has the need?
• What? - What does the user want to happen?
• Why? - What is the benefit the user will receive?

Template:

As a <user> (Who?)

I want <need> (What?)

So that <benefit> (Why?)

INVEST Acronym

To help write user stories, we can use the INVEST acronym:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

Well-written user stories are the foundation for effective agile development, ensuring that user needs are met clearly and efficiently.

Example 1: E-commerce

User Story:

As a customer of an e-commerce site

I want to receive notifications of promotions and discounts

So that I can take advantage of special offers and save money

Acceptance Criteria:

- The customer should be able to sign up to receive email notifications.

- Notifications should be sent automatically when new promotions are available.

- The customer should be able to unsubscribe at any time.

Example 2: Banking App

User Story:

As a user of a banking app

I want to view my balance and recent transactions

So that I can monitor my finances quickly and easily

Acceptance Criteria:

-The user should be able to log in securely.

-The balance and transactions should be updated in real-time.

-The user should be able to filter transactions by date and type.

Example 3: Online Education Platform

User Story:

As a student of an online education platform

I want to access study materials and video lessons

So that I can study and review course content

Acceptance Criteria:

-The student should be able to access study materials after logging in.

-Video lessons should be available in high quality.

-The student should be able to mark videos as “watched” to track their progress.

The 3 Cs of Ron Jeffries

Ron Jeffries proposes three important elements for writing a user story:

• Card - Stories are traditionally written on a card.
• Conversation - Details emerge during conversations with the Product Owner.
• Confirmation - Acceptance criteria confirm that the story has been coded correctly.

Acceptance criteria are essential to ensure that the user story meets the requirements and is accepted by the Product Owner. They should be written before the implementation begins.

Example of Acceptance Criteria for Pix Payment

To make a payment with Pix, the functionality must meet the following criteria:

The customer must have a registered Pix key in their account.

Confirm the payment with a 6-digit token.

The payment amount must be deducted from the payer’s balance within 10 seconds.

Using BDD for Acceptance Criteria

Behavior Driven Development (BDD) is an approach that uses executable specifications to validate the acceptance criteria of a story.

Template:

Scenario 1: Title

Given <initial context>

When <event or action>

Then <expected result>

Example of a BDD Scenario:

Scenario 1:

Title: Log in to the system:

Given the username and password fields are filled

When the “Login” button is clicked

Then the “Home” screen is displayed

Developed by Dan North, BDD uses a common language to describe software behavior, typically employing Gherkin syntax, which is easy for everyone involved to understand. This approach not only enhances communication among teams but also facilitates the creation of automated tests that validate software behavior. This criterion can be easily converted into an automated test that verifies if the functionality is working correctly.

Well-defined user stories and clear acceptance criteria are crucial for agile development success. Techniques like BDD and the INVEST acronym help create user stories that improve communication and enable effective automated testing.

Adopting these practices boosts software efficiency and quality, delivering real value to users and stakeholders. I hope this article has provided valuable insights for your agile projects. If you need more information, I’m here to help!