If you’ve ever written a user story that came back with comments like “What does this mean?” or “Can you clarify the acceptance criteria?” — this post is for you.

Writing clear user stories in English is a skill. It’s not just grammar. It’s about structure, precision, and knowing what your product owner and team actually need to approve a ticket. For Vietnamese developers working in international teams, the challenge is double: technical clarity and language clarity.

Let’s fix that.

The Standard Format — And Why It Matters

The classic user story format is:

As a [user type], I want to [action], so that [benefit].

Simple, right? But in practice, many Vietnamese developers write something like:

“User can log in with Google.”

This works on a sticky note. It does not work in Jira when your product owner is in Berlin and has 40 other tickets to review.

Here’s the same story done properly:

As a registered user, I want to sign in using my Google account, so that I don’t have to remember a separate password for this platform.

The difference: the so that clause explains business value. Without it, engineers build the feature but nobody can defend it in a roadmap meeting.

Key Phrases for Writing User Stories

Starting the story:

  • “As a [first-time user / admin / customer / guest]…”
  • “As a returning customer who has items in their cart…”
  • “As a team member with read-only permissions…”

Describing the action:

  • ”…I want to be able to filter results by date range…”
  • ”…I want to receive a notification when…”
  • ”…I want to export my data as a CSV file…”
  • ”…I need the system to automatically save my progress…”

Stating the benefit:

  • “…so that I don’t have to manually re-enter information.”
  • “…so that I can quickly identify overdue tasks.”
  • “…so that the team has visibility into my progress.”
  • “…so that we reduce the risk of data loss.”

Writing Acceptance Criteria in Plain English

Acceptance criteria (AC) tell the developer and tester exactly when the story is done. Vague AC is one of the top reasons tickets get stuck in review.

Weak AC (what many Vietnamese devs write):

- User can log in
- Error shown if wrong password
- Works on mobile

Strong AC (what gets approved):

Given I am on the login page
When I enter my registered email and correct password
Then I am redirected to my dashboard within 2 seconds

Given I enter an incorrect password
When I click "Sign In"
Then I see the message: "Incorrect email or password. Please try again."
And my account is NOT locked after the first failed attempt

Given I am on a mobile device (viewport < 768px)
When I open the login page
Then all form fields and the Sign In button are fully visible without horizontal scrolling

This is the Given / When / Then format (also called Gherkin). You don’t need to memorize fancy syntax — just think:

  • Given: the starting condition
  • When: the action taken
  • Then: the expected result

Example Dialogues: Backlog Refinement Meeting

Scene: You’re refining a ticket about user notifications

Product Owner (Sarah): Thuan, can you walk us through this story?

You: Sure. The story is: As a project member, I want to receive an email notification when a task is assigned to me, so that I can respond promptly without checking the app constantly.

Sarah: Looks good. What are the acceptance criteria?

You: Three main scenarios. First — when a task is assigned, the assignee gets an email within one minute. Second — the email includes the task title, due date, and a direct link. Third — if the user has turned off email notifications in their settings, no email is sent.

Sarah: Perfect. What’s the estimate?

You: We’re thinking three points. The email template is straightforward, but we need to hook into the notification settings — that adds a bit of complexity.

Scene: Pushing back on vague requirements

Product Owner: Can we add a story for “better search”?

You: I want to make sure we build the right thing. Could you help me understand what “better” means here? For example, are we talking about faster results, more relevant ranking, or additional filters?

Product Owner: Mainly the filters — users keep asking to filter by category and date.

You: Got it. So the story would be: As a user, I want to filter search results by category and date range, so that I can find relevant content faster. Does that capture it?

Product Owner: Yes, exactly.

Notice the phrase: “I want to make sure we build the right thing.” This is polite, professional, and it redirects without making anyone feel questioned.

Common Mistakes Vietnamese Speakers Make

1. Writing in imperative (command) form

Wrong: “Add button for export CSV.” Right: “As a data analyst, I want to export the report as a CSV file, so that I can process it in Excel.”

The imperative form sounds like a task, not a user need. It skips the why, which is essential for prioritization.

2. Using “should” and “must” interchangeably in AC

  • “The system should…” = preferred but optional
  • “The system must…” = required, non-negotiable

In acceptance criteria, almost everything is a must. Write: “The system must display an error message” — not “should” unless you genuinely mean it’s optional.

3. Forgetting negative scenarios

Most Vietnamese developers write AC for the happy path only. But your tester will immediately ask: “What happens if the user is offline? What if the file is too large? What if the session expires?”

Add at least one negative or edge-case scenario to every story. It saves a round-trip in review.

4. Over-specifying the implementation

Wrong: “As a user, I want the system to call the /api/v2/auth/google endpoint using OAuth 2.0…”

The user story is about what and why, not how. Put implementation details in technical notes or a sub-task — not in the story itself.

Quick Templates You Can Reuse

New feature:

As a [user type], I want to [action], so that [benefit].

Improvement:

As a [user type], I currently [pain point]. I want to [improvement], so that [benefit].

Bug fix (as a story):

As a [user type], I expect [correct behavior], but currently [wrong behavior]. This should be fixed so that [impact].

Non-functional requirement:

The [feature] must [performance/security/accessibility requirement] to ensure [reason].

Final Thought

Good user stories are a communication tool, not a paperwork exercise. When you write them clearly in English, you reduce back-and-forth, speed up approvals, and build trust with your product owner and international stakeholders.

The next time you open Jira to write a ticket, ask yourself three questions: Who is this for? What do they want to do? Why does it matter? Answer those in English, add three Given/When/Then scenarios, and your ticket will move faster than most on the board.

Export for reading

Comments