I was reviewing a user story with a team lead years ago, and something felt off. The story described a viewport change — how a web page needed to adjust how it displayed information. Technical enough. Clear enough. But I stopped him.
“How is this valuable?”
He looked at me, a bit puzzled. “What do you mean?”
“I mean,” I said, “this story is telling us what needs to change and how it needs to change. But it’s not telling us why.”
He explained the viewport change. I nodded, listened, and then asked: “How does this bring value to the user, customer, or business?”
The Back and Forth
We went back and forth for a while. I kept pressing: Why is this work necessary? Not in a confrontational way — I genuinely wanted to understand. The story was written from a technical perspective, and that’s not unusual.
Eventually, we got there.
The feature, as it was currently built, was frustrating users on mobile devices. As they scrolled to find information, other important details would disappear off the screen. By the time they found what they were looking for, they’d lost track of something else they needed. So they’d scroll back up. Then down again. Then back up.
And then? They’d give up. They wouldn’t complete their order.
The Real Problem Emerges
Now we had something. The business was losing sales. Users were frustrated. They couldn’t easily access the information they needed to make a confident purchase, so they abandoned the process.
That was the problem worth solving.
Not “the viewport needs to change.” The problem was that users were giving up because they couldn’t keep track of the information they needed to complete their purchase.
Outcomes Over Outputs
From the book Outcomes Over Outputs: An outcome is a change in human behavior that drives business results..
In this case, the human behavior was users getting frustrated and abandoning their orders. That behavior was not driving business results. It was doing the opposite.
The behavior we wanted? Users feel confident and empowered as they find what they need and complete their purchase. That behavior drives business results.
The viewport change? That was just one possible way to enable the behavior we wanted. It was an output — a deliverable. But the outcome was the shift in user behavior.
Why This Matters
When we write user stories that describe technical implementations, we’re skipping over the most important part: the why. We’re jumping straight to a solution without clearly articulating the problem.
And when we do that, we lose something critical. We lose the ability to question whether this is the right solution. We lose the ability to explore alternatives. We lose the connection between the work we’re doing and the value it’s supposed to create.
I’m not saying every story needs to be a philosophical treatise. But I am saying that if I can’t explain how a story improves someone’s life or drives a business result, then I don’t fully understand what I’m building.
What This Looks Like in Practice
Here are some examples of how stories shift when we focus on outcomes instead of outputs:
The Mobile Checkout Story:
Before:
As a developer
I need to modify the viewport settings on the checkout page
So that information remains visible when users scroll on mobile devices
After:
In order to confidently complete my order without losing track of important information like pricing, shipping costs, and product details
As a mobile shopper
I want to easily access all order details while reviewing my purchase
API Integration:
Before:
As a developer
I need to implement a REST API endpoint that returns user profile data in JSON format with OAuth2 authentication
After:
In order to pick up where I left off regardless of which device I'm using
As a user
I want my profile information to sync across all my devices
Database Performance:
Before:
As a developer
I need to add database indexes to the orders table on the customer_id and order_date columns
So that query performance improves
After:
In order to resolve customer issues without making them wait on hold
As a customer service representative
I need to quickly access a customer's order history during support calls
Email Notifications:
Before:
As a developer
I need to implement an email notification service using SendGrid
So that notifications trigger when order status changes
After:
In order to plan to be home to receive my package and know it arrived safely
As a customer
I want to know when my order ships and when it's delivered
Notice the pattern? The “Before” stories focus on technical implementation details from a developer perspective. The “After” stories focus on human needs and the behavior change we’re trying to enable. The technical details — viewport settings, REST APIs, database indexes, SendGrid — become implementation choices, not the story itself.
What I’m Noticing Lately
I’ve been seeing this pattern more often — stories written as technical tasks, disconnected from the human behavior they’re meant to influence. It’s understandable. That’s what happens when we think solely as software developers; we think in terms of code, components, and configurations.
But the best work I’ve done has always started with a clear understanding of the problem (and the need behind it). Not the technical problem. The human problem.
When I can identify the frustration, confusion, or obstacle someone is facing, the technical solution becomes clearer. And more importantly, I can tell when I’m done. Not when the code works, but when the behavior changes.
What would change if your next user story started with the human behavior you’re trying to influence?
