Thuan: I always thought refinement was just “pre-planning.” Read the stories, nod, move on.
Alex: And then sprint planning starts and everyone discovers the stories are vague, the acceptance criteria are missing, and nobody agrees on what “search should be fast” means?
Thuan: Are you reading my Jira board?
Alex: I don’t need to. Bad refinement is the #1 cause of bad sprints — in any language. But for non-native speakers, refinement is especially hard because it requires asking probing questions. And asking questions in a second language feels like admitting you don’t understand.
Thuan: It does. I worry people will think my English is the problem, not the story.
Alex: Then let me give you questions so sharp that people will think your English is the least interesting thing about you.
The Six Types of Refinement Questions
Alex: Great refinement questions fall into six categories. Master these and you’ll catch 90% of issues before they become sprint problems.
1. Clarification Questions — “What Exactly?”
These fight vague requirements:
| Vague Story | Your Question |
|---|---|
| ”The search should be fast" | "What’s our target response time? Under 200ms? Under 1 second?" |
| "Users can manage their profile" | "What fields can they edit? Can they delete their account? Change their email?" |
| "The system should handle errors" | "What should the user see when an error occurs? A toast, a page, a retry button?" |
| "Support multiple languages" | "Which languages specifically? And does that include RTL languages like Arabic?” |
Template: “When you say [vague term], what specifically do you mean?“
2. Edge Case Questions — “What If?”
These catch hidden complexity:
| Story | Your Question |
|---|---|
| ”Users can upload a profile photo" | "What if they upload a 50MB file? What formats do we support? What about offensive content?" |
| "Send a notification when order ships" | "What if the email bounces? What if they’ve unsubscribed? What about timezone?" |
| "Allow users to cancel subscription" | "What happens to their data? Can they resubscribe? Is there a grace period?" |
| "Import data from CSV" | "What if the CSV has 1 million rows? Duplicate entries? Missing required fields?” |
Template: “What should happen if [edge case]?“
3. Acceptance Criteria Questions — “How Do We Know It’s Done?”
| Situation | Your Question |
|---|---|
| No AC written | ”Can we define the acceptance criteria before we estimate?” |
| AC too vague | ”This says ‘user sees a confirmation.’ What does the confirmation look like? A modal, a toast, a redirect?” |
| Missing negative cases | ”The AC covers the happy path. What about error states? What if the API is down?” |
| No performance criteria | ”Should we include a performance target? Like ‘page loads in under 2 seconds?’” |
Template: “How will QA know this is working correctly?“
4. Dependency Questions — “Who Else Is Involved?”
| Situation | Your Question |
|---|---|
| External API | ”Does this depend on [team]‘s API? Is it ready? What’s their timeline?” |
| Design needed | ”Do we have approved designs for this? Or is the dev team deciding the UI?” |
| Database changes | ”This requires a schema change. Do we need a migration plan?” |
| Another team’s work | ”This overlaps with [team]‘s feature. Have we synced with them?” |
Template: “Is there anything outside our control that could block this?“
5. Scope Questions — “Are We Sure About This?”
| Situation | Your Question |
|---|---|
| Gold-plating | ”Do we need the advanced filter for MVP, or can we ship with basic search first?” |
| Hidden scope | ”This says ‘admin page.’ But admin pages always grow — are we sure this is a 3-pointer?” |
| Feature creep | ”I notice two new requirements since last week. Are these committed scope or nice-to-haves?” |
| Over-engineering | ”Do we need real-time sync, or would polling every 30 seconds work for V1?” |
Template: “Is this the minimum we need, or is there a simpler version that delivers value?“
6. Technical Risk Questions — “What Could Go Wrong?”
| Situation | Your Question |
|---|---|
| New technology | ”We haven’t used [X] before. Should we spike it first?” |
| Performance concern | ”This query joins five tables. Have we thought about performance at scale?” |
| Security | ”This endpoint exposes user data. What’s the authorization model?” |
| Data integrity | ”If this fails halfway through, what’s the rollback plan?” |
Template: “What’s the biggest risk here, and how do we mitigate it?”
The Art of Challenging a BA (Politely)
Thuan: This is the hard part. The BA writes a story, and I know it’s incomplete or wrong. But how do I say that without sounding like I’m attacking them?
Alex: The golden rule of professional disagreement: question, don’t accuse.
❌ Accusatory (Avoid)
- “This story is unclear.”
- “You didn’t think about edge cases.”
- “This won’t work.”
✅ Questioning (Use These)
- “I have a few questions about this story — could we walk through the flow together?”
- “I want to make sure I understand the expected behavior for [edge case].”
- “I think there might be some hidden complexity here. Can we break it down?”
- “This makes sense for the happy path. Can we also define what happens when [X]?”
Thuan: So I’m not saying “your story is bad” — I’m saying “let me help make it better.”
Alex: Exactly. The phrasing changes the dynamic from adversarial to collaborative. And the BA will thank you — because you’re catching problems now instead of during the sprint.
The “Yes, And” Technique
When a BA proposes something you think is too complex:
BA: “Users should see a real-time dashboard with live metrics.”
You: “That’s a great end goal. For V1, could we start with a dashboard that refreshes every 30 seconds? That way we ship faster and validate the design before investing in WebSocket infrastructure.”
You’re not saying “no.” You’re saying “yes — and here’s how we get there safely.”
Full Refinement Dialogue Example
Thuan: Show me a complete refinement conversation.
Alex: Here’s a realistic exchange:
BA: Next story — “As a user, I want to export my order history to PDF.”
Thuan: A few questions. First: how much history? Last 30 days? All time?
BA: Good question. Let’s say last 12 months.
Thuan: Got it. And what should the PDF look like? Do we have a design?
BA: Not yet. We were thinking a simple table.
Thuan: Okay. One edge case: what if a user has 5,000 orders? That’s a big PDF. Should we paginate it, or limit it, or generate it async?
BA: Hmm, didn’t think about that. Let’s add a limit — last 100 orders — and a note saying “for full history, contact support.”
Thuan: Makes sense. Last question — should the PDF be generated client-side or server-side? Client-side is faster to build but less reliable. Server-side is more work but handles large datasets better.
BA: Let’s discuss with the team. Maybe we spike it for a day.
Thuan: Sounds good. I’ll create the spike ticket after this meeting.
Thuan: That felt natural. I asked specific questions, caught scope issues, and proposed solutions.
Alex: And you did it in plain English. No fancy vocabulary — just clear, structured thinking expressed in simple words.
10-Minute Self-Practice
The “What If” Game (Solo Practice)
- Pick any feature you’re working on
- Set a 5-minute timer
- Write down as many “What if…” questions as you can
- For each question, write the phrase you’d use in a meeting:
- “What should happen if [X]?”
- “Have we considered the case where [Y]?”
- “I’d suggest we define behavior for [Z].”
The Story Review Practice
- Open a random user story from your backlog
- Read it once
- Write 3 questions using the six categories above
- Say each question out loud — practice the phrasing
Thuan: I can do this during my lunch break with real tickets.
Alex: That’s the beauty of it. You’re not studying English — you’re preparing for refinement. The English improvement is a side effect.
What’s Next
Now you can ask the questions that prevent bad sprints. In the next post, we’ll cover Sprint Review and Demo Day — how to present your team’s work to stakeholders without sounding like you’re reading from a script.
This is Part 4 of the English Upgrade series — practical Business English for busy tech leads. Cross-reference with English Upgrade #3: Sprint Planning for the full sprint ceremony toolkit.
Related: Tech Coffee Break #2: API Design — good APIs come from good requirements. This post helps you get those requirements right.