Thuan: My BA wrote a story that says: “The system should handle all edge cases.” That’s the entire acceptance criteria.
Alex: laughs “Handle all edge cases” — the most meaningful and yet completely meaningless requirement ever written.
Thuan: I know it’s bad. But I don’t know how to push back without sounding like I’m being difficult. In Vietnamese culture, challenging someone else’s work — especially someone from a different team — feels confrontational.
Alex: In software, unclear requirements are the #1 source of wasted effort. Pushing back isn’t being difficult — it’s being professional. Let me teach you how to do it in English that’s both polite and effective.
The Requirement Quality Check
Alex: Before you push back on a story, run it through this mental checklist:
| Quality Check | Question to Ask |
|---|---|
| Specific | Can two developers read this and build the same thing? |
| Testable | Can QA write a test case from this? |
| Bounded | Is the scope clear — what’s included AND excluded? |
| Feasible | Can we actually build this with our current stack/timeline? |
| Sized | Is it small enough for one sprint? |
If any answer is “no,” you have a conversation to start.
Essential Phrases for Requirement Discussions
Asking for Clarity
| Situation | Phrase |
|---|---|
| Story is vague | ”This story is a good starting point. Could we add more detail to the acceptance criteria?” |
| Missing context | ”I want to make sure I understand the business goal. What problem are we solving for the user?” |
| Ambiguous wording | ”When you say ‘the system should handle errors,’ could you specify which errors and how they should be handled?” |
| Missing flow | ”Could you walk me through the user journey from start to finish?” |
| Undefined terms | ”You mention ‘premium users’ — is that defined somewhere? Who exactly qualifies?” |
Challenging Scope
| Situation | Phrase |
|---|---|
| Too big | ”I think this story is actually an epic. Can we break it down into smaller, independent stories?” |
| Gold-plating | ”Do we need the auto-save feature for V1, or can we ship with a save button first?” |
| Scope creep | ”I noticed three new requirements since last week. Are these additions or replacements?” |
| Hidden complexity | ”This looks straightforward, but syncing across devices adds significant complexity. Should we discuss the trade-offs?” |
| Missing MVP | ”What’s the simplest version of this that delivers value? Can we ship that first?” |
Negotiating Solutions
| Situation | Phrase |
|---|---|
| Proposing alternative | ”Instead of real-time sync, what about polling every 30 seconds? It’s 80% of the value with 20% of the effort.” |
| Suggesting phases | ”How about we split this into two phases? Phase 1: basic functionality. Phase 2: advanced features.” |
| Trade-off discussion | ”We can do A or B this sprint, but not both. Which has higher business value?” |
| Technical constraint | ”The current architecture doesn’t support that easily. Here’s what we’d need to change, and the timeline impact.” |
Real Dialogue: Pushing Back on a Bad Story
Thuan: Show me the full conversation.
Alex: Let’s roleplay. I’m the BA, you’re you:
BA: “Here’s the story: ‘As a user, I want to search for products so that I can find what I’m looking for.’”
Thuan: “That’s a good user story at the epic level. But for implementation, I need more detail. A few questions:”
Thuan: “First — what fields should be searchable? Product name only, or also description, category, SKU?”
BA: “Hmm, name and description for now.”
Thuan: “Got it. Second — should search support typos? Like if someone types ‘iphon’ for ‘iPhone’?”
BA: “That would be nice. Is it hard?”
Thuan: “Fuzzy search adds complexity. We’d need Elasticsearch instead of a simple SQL query. That changes the estimate from 3 points to 8. Is it worth it for V1?”
BA: “Let’s skip fuzzy search for now. Exact match is fine for V1.”
Thuan: “Smart choice. Third question — what should happen when there are no results? Do we show ‘No results — try a different search’ or suggest alternatives?”
BA: “Just a ‘no results’ message for now.”
Thuan: “Perfect. One more — is there a max number of results? If the search returns 10,000 products, should we paginate?”
BA: “Yes, 20 per page.”
Thuan: “Great. Can you update the acceptance criteria with these decisions? I’ll estimate it at 5 points once that’s done.”
Thuan: That felt collaborative, not combative.
Alex: Because you used questions, not statements. You didn’t say “your story is bad.” You said “I need more detail to build this correctly.” The outcome is the same — better requirements — but the relationship stays strong.
When the BA Pushes Back on YOU
Thuan: What if the BA disagrees? “No, the story is clear enough.”
Alex: That happens. Here’s how to handle it:
When BA Says “It’s Clear Enough”
“I understand, and I appreciate the work. My concern is that without [specific detail], two developers might build different things. Could we spend 5 minutes clarifying [X]? It’ll save us time during the sprint.”
When BA Says “Just Build What Makes Sense”
“I can make technical decisions, but product decisions should come from the product side. For example, if there are no search results, should we show suggestions? That’s a product decision that affects the user experience.”
When BA Says “We Don’t Have Time to Detail Everything”
“I agree we should be efficient. What if I draft the acceptance criteria based on my understanding, and you review and confirm? That way it takes 5 minutes of your time instead of 30.”
Thuan: That last one is brilliant. I do the work, they just confirm.
Alex: It’s called “propose and validate.” Write the AC yourself, send it to the BA, and say: “Here’s what I’m planning to build. Does this match your vision?” Nine times out of ten, they’ll say yes — and now you have clear requirements.
The “Propose and Validate” Email Template
Subject: Confirming scope: [Story Name]
Hi [BA Name],
Following our discussion, here's my understanding of [Story Name]:
**What we'll build:**
- Search by product name and description
- Exact match (no fuzzy search in V1)
- 20 results per page with pagination
- "No results found" message for empty searches
**What we're NOT building (for now):**
- Fuzzy/typo-tolerant search
- Search suggestions
- Advanced filters (category, price range)
Could you confirm this matches your expectations?
I'll finalize the estimate once confirmed.
Thanks,
ThuanThuan: This email also protects me. If the BA says “yes” and later changes their mind, I have documentation.
Alex: Exactly. Professional communication isn’t just about clarity — it’s about creating a shared record. In English business culture, “I sent an email and they confirmed” is a legitimate defense.
Common Vietnamese Speaker Mistakes in BA Discussions
1. Being Too Indirect
❌ “Maybe we could perhaps consider possibly adding a bit more detail…?” ✅ “We need more detailed acceptance criteria before we can estimate.”
2. Saying “Yes” When You Mean “I Have Questions”
❌ nods silently → builds the wrong thing ✅ “I understand the goal. I have some questions about the details.”
3. Avoiding the Word “No”
❌ “That might be challenging…” (BA hears: “it’s fine”) ✅ “That’s not feasible in one sprint. Here’s what we can do instead.”
4. Over-Apologizing
❌ “Sorry, I’m sorry to bother you, but maybe the story could use a tiny bit more detail?” ✅ “Could we add acceptance criteria? It’ll help the team estimate accurately.”
10-Minute Self-Practice
The Story Audit (5 min)
- Open your Jira/Linear backlog
- Pick the vaguest story you can find
- Write 3 questions using the patterns from this post
- Write a “Propose and Validate” email for that story
- Say one question aloud: “What should happen if [X]?”
The “What If” Brain Dump (5 min)
- Pick any feature your team is building
- In 5 minutes, write every edge case you can think of
- For each, write: “What should happen when [X]?”
- Bring these to the next refinement meeting
What’s Next
You can now negotiate requirements like a pro. Next post: Dev vs QC — Bug Discussions — how to discuss bugs, defend your code, and accept feedback without ego.
This is Part 7 of the English Upgrade series. Pairs perfectly with English Upgrade #4: Refinement — where these conversations typically happen.
Related: Tech Coffee Break #2: API Design — because good requirements lead to good APIs.