The Illusion of Clarity or why User Stories are harder than they look

Claas
Jul 17, 2025
6 min read

In nearly every major transformation project I’ve worked on, whether in CRM, ERP, or broader digital initiatives, there comes a point where someone says, “Let’s just write user stories.” It’s become the go-to solution for capturing requirements in agile environments. The phrase itself carries a kind of confidence, as if everything else will fall into place once we’ve documented the needs using the right format. And the format is everywhere:

“As a [role], I want [feature], so that [benefit].”

It's clean. Compact. Easy to teach and easy to scale. It fits into Jira, into sprints, into SAFe boards and agile ceremonies. In theory, it bridges the gap between business and delivery. It promises clarity, alignment, and speed.

But the reality is different. Writing user stories is often treated as a routine activity, a box to check rather than the thinking exercise it’s meant to be. And over time, I’ve come to believe that while user stories are one of the most visible artifacts in consulting and delivery work, they’re also one of the most misunderstood.

Because here's the uncomfortable truth: You can write dozens or even hundreds of user stories that follow the format perfectly - and still completely miss the point.

The myth of the “ready-made backlog”

I’ve reviewed proposals with 100+ user stories where not one of them was actually useful. I’ve joined projects where the backlog was fully written, but completely disconnected from what the business actually needed.

Too often, the stories are:

Technical requirements rewritten into user-friendly phrasing.
Descriptions of existing systems disguised as future needs.
Functionality that’s already standard presented as if it requires custom design.

You read through the backlog and quickly realize: this isn’t discovery, it’s reverse documentation.

In CRM and ERP implementations, this happens all the time. A team is tasked with delivering a backlog, and in their rush to produce, they end up wrapping the past in the language of the future.

User stories were never meant for this

To understand the problem, we have to go back to the origins of agile and of user stories.

Agile was designed for uncertainty. For building software that didn’t exist yet. For adapting to changing user needs and evolving market conditions. The user story format was a lightweight way to capture intent and drive iteration.

It was never meant to document known processes or describe off-the-shelf system behavior.

But that’s what we often see in practice:

“As a finance user, I want to post journal entries so that I can close the books.”
“As a customer service agent, I want to access the account screen so that I can view the latest case.”

These aren’t user stories. These are business-as-usual, described in agile clothing.

When agile is applied to the known, not the new

And this leads to a bigger truth: agile methodology isn’t always used where it

fits best. In innovation-driven product teams, agile thrives. You’re iterating toward something that doesn’t exist. You discover the user need as you go. User stories drive design and interaction.

But in many enterprise projects especially in ERP or CRM we already know the system. We already know the functionality. The goal is not to invent, but to apply. And yet, we still force every team to write user stories. Even when the solution is already decided. Even when the "requirement" is to use a drop-down menu that’s always been there.

It becomes a ritual and like all rituals, it stops adding value when no one remembers why it exists.

The CRM example: the story that looks right (but isn’t)

Let’s get specific. A common scenario in a CRM project: the user wants more visibility into pipeline performance. A business analyst writes:

“As a sales manager, I want a new dashboard so that I can monitor my team’s performance.”

It fits the format. It sounds plausible. But if you look deeper: “Dashboard” is already a solution. “Monitor performance” is vague. No one has asked what behavior is supposed to change. So the team builds the dashboard. It goes live. And then: no one uses it.

Let’s Try Again — and Still Get It Wrong

A more experienced consultant might revise it:

“As a sales manager, I want a customizable dashboard with filters so that I can track KPIs in real time.”

Better phrasing. More detail. Still the wrong story.

We’re still assuming that the answer is a dashboard. We’re still not questioning the need. We’ve improved the format, but not the thinking.

The Real Story Starts With a Real Need

Now let’s dig into what the manager actually wants:

“As a sales manager, I want to identify which reps are falling behind on pipeline creation so I can coach them before they miss their targets.”

This is a story that matters. It describes a specific pain. It implies an action. It connects to a business outcome.

But here’s the twist: it doesn’t tell you what to build. And that’s the discomfort many teams feel. It’s a great story, but it doesn’t map to a feature. Not immediately.

When a great story has no immediate solution

At this point, the delivery team pauses. What should we build? A dashboard? Maybe. A report? Possibly. A weekly email summary that flags coaching needs? A stronger option. A structured 1:1 framework? Even better.

A CRM nudge that alerts managers based on pipeline trends? Now we’re thinking. What we’re seeing here is real design work. Creative thinking. Consulting, not just documenting.

And that’s what a great user story unlocks.

The danger in treating every requirement as a story

Of course, not every part of a system is meant to be discovered. Some things are just standard. So what happens when we write stories for those too?

We get: Dozens of low-value backlog items. Teams who focus on finishing tickets, not solving problems. Stakeholders who lose interest in grooming sessions.

This is not agile. It’s agile theater. So what’s the alternative?

Here’s where we need to be more honest and more flexible. Not everything needs to be a user story. Instead, we can take a hybrid approach: Use user stories for areas that involve behavior change, open questions, or real user impact. Use fit-gap documentation, process blueprints, or functional specifications when describing how known platform features will be configured.

This is not about rejecting agile, it’s about using it where it works best.

If you know what the solution is, describe the decision and move on. If you don’t, use stories to explore.

The goal is not story coverage. The goal is clarity.

This gets missed in agile teams because agile encourages decentralization. Everyone can write a story. That’s good but also risky. Because unless someone is challenging those stories, you end up with a backlog full of assumptions. The team runs fast, but in the wrong direction.

Agile says “working software over comprehensive documentation.” But if the stories don’t represent meaningful needs, what exactly are we working toward?

Conclusion: the real work begins after the story

Here’s what I tell teams now: A user story is not a requirement. It’s a prompt for discovery. If you treat it as a specification, you’ll build what was asked for and miss what was needed. If you treat it as a placeholder for a conversation, you’ll uncover what matters - and deliver something that sticks.

In some cases, stories will lead to dashboards, reports, or alerts. In others, they’ll lead to better coaching, tighter processes, or smarter decisions.

But only if you’re willing to ask:

What’s really behind this request?
Who benefits?
What problem are we actually solving?

User stories are a tool. A good one. But like all tools, they only help if we use them with intention. Because at the end of the day, writing stories is easy. Delivering value is the hard part.

Epilogue

I wrote this text prior to the one on self-building systems, but taking both together creates an interesting paradox. The kind of "bad" user stories I was critical of - technical, prescriptive, focused on features - are probably the ones a self-building system could act on most easily. They are structured, direct, and close to executable logic.

Still, I believe the "good" stories matter more. The ones that describe a need rather than a solution. Because even in a future where systems build themselves, we will still need an intermediate step. A moment to define intent, understand the context, and decide how we want to solve the problem.

Whether we call it a user story, a requirement, or a prompt does not really matter. What matters is that someone takes the time to ask what is worth building and why.

“As a [role], I want [feature], so that [benefit].”

It's clean. Compact. Easy to teach and easy to scale. It fits into Jira, into sprints, into SAFe boards and agile ceremonies. In theory, it bridges the gap between business and delivery. It promises clarity, alignment, and speed.

Because here's the uncomfortable truth: You can write dozens or even hundreds of user stories that follow the format perfectly - and still completely miss the point.

The myth of the “ready-made backlog”

I’ve reviewed proposals with 100+ user stories where not one of them was actually useful. I’ve joined projects where the backlog was fully written, but completely disconnected from what the business actually needed.

Too often, the stories are:

Technical requirements rewritten into user-friendly phrasing.

Descriptions of existing systems disguised as future needs.

Functionality that’s already standard presented as if it requires custom design.

You read through the backlog and quickly realize: this isn’t discovery, it’s reverse documentation.

In CRM and ERP implementations, this happens all the time. A team is tasked with delivering a backlog, and in their rush to produce, they end up wrapping the past in the language of the future.

User stories were never meant for this

To understand the problem, we have to go back to the origins of agile and of user stories.

Agile was designed for uncertainty. For building software that didn’t exist yet. For adapting to changing user needs and evolving market conditions. The user story format was a lightweight way to capture intent and drive iteration.

It was never meant to document known processes or describe off-the-shelf system behavior.

But that’s what we often see in practice:

“As a finance user, I want to post journal entries so that I can close the books.”

“As a customer service agent, I want to access the account screen so that I can view the latest case.”

These aren’t user stories. These are business-as-usual, described in agile clothing.

When agile is applied to the known, not the new

And this leads to a bigger truth: agile methodology isn’t always used where it

fits best. In innovation-driven product teams, agile thrives. You’re iterating toward something that doesn’t exist. You discover the user need as you go. User stories drive design and interaction.

It becomes a ritual and like all rituals, it stops adding value when no one remembers why it exists.

The CRM example: the story that looks right (but isn’t)

Let’s get specific. A common scenario in a CRM project: the user wants more visibility into pipeline performance. A business analyst writes:

“As a sales manager, I want a new dashboard so that I can monitor my team’s performance.”

It fits the format. It sounds plausible. But if you look deeper: “Dashboard” is already a solution. “Monitor performance” is vague. No one has asked what behavior is supposed to change. So the team builds the dashboard. It goes live. And then: no one uses it.

Let’s Try Again — and Still Get It Wrong

A more experienced consultant might revise it:

“As a sales manager, I want a customizable dashboard with filters so that I can track KPIs in real time.”

Better phrasing. More detail. Still the wrong story.

We’re still assuming that the answer is a dashboard. We’re still not questioning the need. We’ve improved the format, but not the thinking.

The Real Story Starts With a Real Need

Now let’s dig into what the manager actually wants:

“As a sales manager, I want to identify which reps are falling behind on pipeline creation so I can coach them before they miss their targets.”

This is a story that matters. It describes a specific pain. It implies an action. It connects to a business outcome.

But here’s the twist: it doesn’t tell you what to build. And that’s the discomfort many teams feel. It’s a great story, but it doesn’t map to a feature. Not immediately.

When a great story has no immediate solution

At this point, the delivery team pauses. What should we build? A dashboard? Maybe. A report? Possibly. A weekly email summary that flags coaching needs? A stronger option. A structured 1:1 framework? Even better.

A CRM nudge that alerts managers based on pipeline trends? Now we’re thinking. What we’re seeing here is real design work. Creative thinking. Consulting, not just documenting.

And that’s what a great user story unlocks.

The danger in treating every requirement as a story

Of course, not every part of a system is meant to be discovered. Some things are just standard. So what happens when we write stories for those too?

We get: Dozens of low-value backlog items. Teams who focus on finishing tickets, not solving problems. Stakeholders who lose interest in grooming sessions.

This is not agile. It’s agile theater. So what’s the alternative?

This is not about rejecting agile, it’s about using it where it works best.

If you know what the solution is, describe the decision and move on. If you don’t, use stories to explore.

The goal is not story coverage. The goal is clarity.

This gets missed in agile teams because agile encourages decentralization. Everyone can write a story. That’s good but also risky. Because unless someone is challenging those stories, you end up with a backlog full of assumptions. The team runs fast, but in the wrong direction.

Agile says “working software over comprehensive documentation.” But if the stories don’t represent meaningful needs, what exactly are we working toward?

Conclusion: the real work begins after the story

In some cases, stories will lead to dashboards, reports, or alerts. In others, they’ll lead to better coaching, tighter processes, or smarter decisions.

But only if you’re willing to ask:

What’s really behind this request?

Who benefits?

What problem are we actually solving?

User stories are a tool. A good one. But like all tools, they only help if we use them with intention. Because at the end of the day, writing stories is easy. Delivering value is the hard part.

Epilogue

Still, I believe the "good" stories matter more. The ones that describe a need rather than a solution. Because even in a future where systems build themselves, we will still need an intermediate step. A moment to define intent, understand the context, and decide how we want to solve the problem.

Whether we call it a user story, a requirement, or a prompt does not really matter. What matters is that someone takes the time to ask what is worth building and why.

Comments