Neglecting the ‘So That’ Clause
One decision separates teams who write stories that deliver real value from those who ship features no one asked for: whether they ask “why” before writing “what.” I’ve seen teams spend weeks building dashboards that no one uses—not because the code was wrong, but because the “so that” clause was missing. Without it, the story becomes a technical task disguised as a user need.
Every time you skip the “so that” clause, you strip the story of its purpose and create a gap between development and value. This isn’t a minor formatting issue—it’s a fundamental misunderstanding of what a user story is supposed to represent.
This chapter shows how to reclaim purpose in user stories, using real-world examples, structured rewrites, and decision-making patterns I’ve used across 200+ product backlogs. You’ll learn how to spot missing purpose, reframe stories with user value expression, and ensure every story connects to a tangible outcome.
The Hidden Problem: Why ‘So That’ Is Not Optional
Many teams treat the “so that” clause as filler. They write: “As a customer, I want to see my order history so that I can track past purchases.” The “so that” is there, but it’s weak. It doesn’t explain *why* tracking matters—just that it exists.
But when the clause is missing entirely, the story becomes a placeholder for work, not a commitment to value. Consider this: “As a user, I want to sort the list by date.”
No context. No outcome. No reason. You can’t test it. You can’t prioritize it. You can’t even explain why it should be done.
That’s the real cost of neglecting the ‘so that’ clause: misplaced effort. Teams build features that don’t solve problems, don’t improve experience, and don’t move the needle on business goals.
How I Know This Is Working
When I hear a team say, “We’ll just build it and see,” I know the ‘so that’ is missing. When a story can’t be explained in one sentence to a non-technical stakeholder, I know it lacks purpose.
Here’s what I’ve learned from experience: the strongest user stories don’t just describe actions—they clarify outcomes. The “so that” clause is where that happens.
What Happens When ‘So That’ Is Missing
Without a purpose, stories become ambiguous, untestable, and disconnected from user needs. This leads to:
- Development based on assumptions instead of evidence
- Acceptance criteria that are guesses, not validations
- Re-work due to misaligned features
- Low team confidence in what to build
- Stakeholder frustration when the output doesn’t match expectations
These problems aren’t caused by poor coding or bad estimation. They stem from one root: the story doesn’t answer why it exists.
When the ‘so that’ is missing, the story can’t be evaluated for value. It becomes a task, not a story. And that’s where Agile breaks down.
How to Reconnect Stories to User Value Expression
Rebuilding purpose isn’t about adding a phrase. It’s about shifting focus from *what* to *why*. Here’s how:
Step 1: Ask “Why?” Until You Hit a User Outcome
Start with the bare functionality. Then ask why it matters. Keep going until you reach a real user benefit.
Example:
Original: “As a user, I want to filter results by category.”
Why? To see only the items I care about.
Why? To make my shopping faster.
Why? To avoid decision fatigue and reduce bounce rate.
Revised: “As a user, I want to filter results by category so that I can focus on the products I care about and reduce decision fatigue.”
The outcome is now clear—and testable.
Step 2: Replace Vague Outcomes with Specific, Measurable Benefits
A weak “so that” clause uses generic terms like “better,” “faster,” or “easier.” These aren’t measurable. Use concrete, user-centric outcomes instead.
Compare:
| Weak Purpose | Strong Purpose |
|---|---|
| so that I can manage my data | so that I can export my analytics report to share with my team |
| so that I can access the system | so that I can check my appointment schedule while on the go |
Notice how the strong version specifies *who*, *what*, and *why*. This is user value expression in action.
Step 3: Use the “Value Test” Before Acceptance
Before a story is accepted, ask:
- What does this change for the user?
- How will we know it’s working?
- Would the user notice the difference?
If you can’t answer all three clearly, the purpose is still missing.
When ‘So That’ Is Misused
Even when the clause is present, it can be misused. Watch for:
- Repetitive or redundant phrasing: “so that I can see the data so that I can analyze it” – this adds no value.
- Technical justification: “so that the backend can scale better” – this is not user value.
- Assumed benefit: “so that it’s easier to use” – what does “easier” mean? No metric.
These aren’t stories. They’re excuses. The ‘so that’ clause must deliver a user-centric outcome, not a developer convenience.
Practical Patterns for Writing Purposeful Stories
Here are three proven patterns I use to ensure ‘so that’ clauses are meaningful and actionable:
1. The Outcome-Based Rewriting
Start with the feature. End with the value. Rewrite until you can say: “If this feature is delivered, the user will be able to do X.”
Example:
- Original: “As a user, I want to save my preferences.”
- Improved: “As a user, I want to save my preferences so that I don’t have to reconfigure my settings every time I log in.”
This is user value expression. The story now has a clear purpose and is testable.
2. The ‘Why Not?’ Challenge
Ask: “Why would a user *not* want this? What’s the risk?”
This reveals hidden assumptions. If the answer is “no one would care,” the story likely lacks purpose.
3. The Customer Impact Matrix
Use a simple matrix to evaluate stories by:
- User impact: High, Medium, Low
- Business impact: High, Medium, Low
Only stories with at least one “High” should be considered for the backlog. This filters out stories where the ‘so that’ clause is missing or weak.
Common Pitfalls and How to Avoid Them
Even with good intentions, teams fall into traps. Here’s how to spot and avoid them:
- Pitfall: Confusing “so that” with “in order to” – these are not synonyms. “In order to” describes action. “So that” describes outcome.
- Solution: Replace “in order to” with “so that” and ask: “What changes for the user?”
- Pitfall: Using the “so that” clause to justify technical decisions.
- Solution: Ask: “Would the user care about this?” If no, it’s not a user story.
- Pitfall: Writing stories with no user at all.
- Solution: Every story must begin with “As a [user role]”—no exceptions.
This isn’t bureaucracy. It’s ensuring consistency in user value expression.
Frequently Asked Questions
Why do some teams still skip the ‘so that’ clause?
Because they confuse stories with tasks. They think writing “I want to add a filter” is enough. But a story must explain why that filter matters. Without the ‘so that’ clause, the team builds without context—and delivers without impact.
Can a story be valid without a ‘so that’ clause?
Technically yes, but not in practice. A story without purpose cannot be tested, prioritized, or validated. It’s a placeholder. Agile requires value-driven development—every story must deliver value.
What if the user value is unclear?
Ask the stakeholder: “What changes for the user if this feature works?” If they can’t answer, the story isn’t ready. Use discovery sessions or user interviews to uncover the real purpose.
Is it okay to have a “so that” clause that’s just “to improve the user experience”?
No. “Improve the user experience” is vague and untestable. It’s a common symptom of missing purpose. Replace it with a specific, measurable outcome: “so that I can complete my purchase in under 60 seconds.”
How do I teach my team to write with purpose?
Start with examples. Show poor vs. strong stories side by side. Have teams rework weak stories using the “Why?” and “Impact” tests. Make it a part of backlog refinement. Over time, purpose becomes second nature.
What if the ‘so that’ clause is too technical?
If it mentions databases, APIs, or performance, it’s not a user story. Reframe it from the user’s perspective. Ask: “What does this mean for my customer?” That’s where user value expression begins.
Final Takeaway
Writing user stories without the ‘so that’ clause is like building a house without a foundation. The structure may look intact, but it collapses under real pressure.
The goal isn’t to write more stories. It’s to write better ones—stories that are rooted in user value expression and grounded in real outcomes.
Remember: a story is a placeholder for a conversation. If the ‘so that’ clause is missing, the conversation never starts.
Go back to your backlog. Find one story with no ‘so that’ clause. Rewrite it using the principles above. You’ll see the difference in clarity, testability, and team alignment.
That’s where real Agile delivery begins.
