The Question Nobody Asks Before Writing a User Story
There is a question that almost never gets asked before a team writes a user story. It is not a technical question. It is not a product question. It is not even a difficult question.
It is this: how does this story fit into where the system is going?
That question sounds simple. In most teams it never gets asked — because most teams have learned to treat each story as a discrete unit of work with a beginning, a middle, and an end. The ticket arrives. The acceptance criteria get written. The story gets estimated. The work begins. And somewhere in that process, the connection between this specific piece of work and the larger thing the team is trying to build quietly disappears.
The result is a backlog full of stories that each make sense individually and don’t quite add up to anything together. Features that work but don’t compound. Improvements that land but don’t move the number. A team that is busy and not building anything.
The Template That Hides the Problem
The “As a user, I want... so that I can...” format was designed to keep stories connected to user value. The “so that” clause is supposed to answer the why — not just what the feature does, but what it enables.
In practice, the “so that” clause almost never does that work.
Watch what happens in a real refinement session. Someone reads the story aloud. The “so that” clause gets recited — so that I can view my account balance — and nobody asks whether that clause actually explains why this story matters, whether it connects to anything the team has agreed they are trying to accomplish, or whether building this thing moves the system closer to where it needs to go.
The template creates the appearance of a why without requiring anyone to think about one. And because the appearance is there, the question doesn’t get asked.
The North Star
The question that changes this is not about the individual story. It is about the system.
Every team should be able to answer: where is this system going? Not in terms of the roadmap — roadmaps change. Not in terms of the next release — releases come and go. But in terms of the fundamental thing this system is supposed to become, the problem it is supposed to solve at its best, the user it is supposed to serve when everything is working the way it should.
That is the North Star. And it is what makes individual stories meaningful or meaningless.
A story written without reference to the North Star is a ticket. It describes a change to the system. It has acceptance criteria. Someone can build it. But it does not answer the question of whether building it moves anything that matters.
A story written with the North Star in mind is something different. The engineer who writes it knows not just what it does but why it belongs in the sequence. They can explain how this piece connects to the larger thing. They can make decisions during implementation when something unexpected comes up — because they understand what they are trying to build, not just what the ticket says.
That engineer does not need to ask their manager what to do when the edge case appears that the story didn’t account for. They already know what direction the system is supposed to move. They make the call that gets it there.
What This Looks Like in Practice
Here is the difference between a story written in isolation and a story written with the North Star in mind.
Without the North Star:
As a user, I want to see my recent transactions on the dashboard so that I can review my account activity.
That story is not wrong. It describes a real feature that a real user might want. But it contains no information about why this feature belongs in the sprint, what it connects to in the larger system, or what success looks like beyond “the feature exists.”
An engineer who builds this story has completed a ticket. They have added a feature. They have no way of knowing whether what they built moved anything that matters — because nothing in the story told them what matters.
With the North Star:
As a user, I want to see my recent transactions on the dashboard so that I can identify unexpected charges without navigating away from the main view — reducing the friction that currently causes users to abandon the session before completing their intended action.
Now the story has a why that connects to something real. The engineer building it understands that the goal is not just to display transactions — it is to reduce session abandonment at a specific point in the flow. They know what success looks like. They can make decisions during implementation that serve that goal. And when they present it in the sprint review, they have something to show beyond a feature — they have a hypothesis about what this change will do to the number.
The Question to Ask in Refinement
The simplest way to introduce the North Star into your refinement sessions is to ask one question before every story gets written or reviewed:
“How does this fit into where the system is going?”
That question will be uncomfortable the first few times. Engineers who have been writing stories in isolation for years will not have an immediate answer. Product owners who have been focused on the immediate roadmap will have to think about it. The scrum master will look at you like you’ve added something to the process.
Let the discomfort sit. The answer to that question is what separates a story from a ticket.
If nobody in the room can answer it — if the team cannot articulate how this piece of work connects to the larger thing they are building — that is information. It means the story is not ready to be written yet. It means there is a conversation that needs to happen before the acceptance criteria get defined.
That conversation is not overhead. It is the work.
What Changes When the Team Has a North Star
When engineers understand where the system is going — when they can see the connection between this ticket and the outcome the team is working toward — three things change.
They make better decisions during implementation. The unexpected edge case, the design choice that the story didn’t specify, the tradeoff between two valid approaches — all of these get resolved faster and better when the engineer knows what direction the system is supposed to move. They are not guessing. They are navigating.
They ask better questions in refinement. The engineer who understands the North Star does not just ask clarifying questions about the acceptance criteria. They ask questions about fit — does this approach get us closer to where we’re going, or does it solve the immediate problem in a way that creates friction later? Those questions change the conversation from execution planning to problem solving.
They write stories that compound. A backlog built around a North Star has a shape. Each story moves the system in a direction. The features accumulate into something rather than just accumulating. And over time the team develops a mental model of the problem space that makes them genuinely difficult to replace — because they understand not just what the system does but what it is becoming.
That is the difference between a team that is closing tickets and a team that is building something.
The Question Worth Asking
Before your next refinement session, try this.
Pull up the first story on the agenda. Before anyone talks about acceptance criteria or estimation or implementation approach, ask the room: how does this fit into where the system is going?
See what happens.
If the room can answer it clearly and quickly, you have a team that is already thinking in terms of the North Star. The refinement session that follows will be more focused, the stories will be better, and the sprint review at the end will have something real to show.
If the room goes quiet — if people look at each other and reach for the template instead of the answer — you have found the gap. And you have found the conversation that needs to happen before the story gets written.
That conversation is where product thinking starts. It is also where the most engaged engineers begin to separate themselves from the ones who are just closing tickets.
The question nobody asks is the one worth asking first.
If this resonated, the thinking behind it goes deeper in my book — Getting Engineers to Give a Damn: A Manager’s Guide to Building Ownership Inside Broken Systems. Written for managers inside large, constrained organizations who are tired of backlogs that don’t add up to anything.