User Story vs. Story Issue Type
How to Tell the Right Story
It all started in a Retrospective. The kind of Retro where you ask the team "what's bothering you the most right now?" and you brace yourself, because when developers actually answer that question honestly, you better be ready.
That particular team was working on an online digital product. By the time of that Retro, we'd been working together for almost 4 months. So when that question landed, the answer was unanimous and immediate:
"The User Story."
Not the Sprint. Not the stakeholders or managers, not the deployment pipeline or the other team. No. The User Story. That little sentence on every single ticket that was supposed to make everything better.
My first reaction: honestly surprised. The User Story is supposed to be this beautiful thing: a promise to have a conversation about customer value! It's one of the first things you learn as a Scrum Master, just how I learned about it from my mentor. And here was my entire team telling me it was the thing they hated most about their daily work.
The format used to start a conversation about customer value.
This frustration existed in a few teams before this one, that much was clear from experience. But never with such unison in an answer from every single member in the team. So in this Retro, the goal was to really crack this open. Not defend it. Not explain why they should love it or why it's such a beneficial conversation to have.
What came out of that conversation has stayed with me.
Inventing Customer Needs
One developer put it so clearly that I've never forgotten it:
"Honestly? I don't want to sit here and 'make up' which customer need my individual ticket fulfills. We've already talked about that when we defined the Sprint Goal! As if every single effort I do creates some separate value for the customer. That's just nonsense for me."
And the rest of the team mumbled in full agreement. Every single one. A full Scrum team of 10 developers.
This wasn't about skipping documentation. The team was rejecting the demand to re-justify customer value on every ticket, when that conversation had already happened at the Sprint Goal level. They'd sat with the Product Owner, aligned the stakeholder needs, understood the why behind the Sprint. And then they were asked to write that same three-part sentence on every Jira ticket. Again and again.
It felt invented. Because it was invented. Half the time, the benefit part was a guessing game. "As a user, I want the database migration to run successfully so that... I can... enjoy a seamless experience?" Come on! Half the user stories included solutions by that point. And that was the opposite of its original intention.
How Did We Even Get Here?
Here's the thing. The User Story was born as a communication tool. The original idea was simple: a card, a conversation, a confirmation, an agreement. The card was just a reminder to talk. It was never meant to be a specification. It was never meant to live on every ticket in your backlog.
But companies like Atlassian built their project management tool and needed issue types. They chose "Story" as the default type for work items. Not "Product Backlog Item” or "Effort" or "Work Item." Whether that was a deliberate methodological choice or simply a naming convention that stuck, the effect was the same: they defined it as the "smallest unit of work in an agile framework."
Suddenly, every ticket in every backlog in every Jira Scrum Project in the world had the label "Story" on it.
And because the issue type was called "Story," teams started putting User Stories on every single one. On the database migration. On the config change. On the bug fix. On the CSS (styling) adjustment. On everything.
The funny thing? Scrum itself never required this.
The Scrum Guide doesn't even mention User Stories — at all! Not a single word. It talks about Product Backlog Items. Even Scrum.org has published articles calling out the myth that backlogs must consist of User Stories. They call it an "administrative burden." (Their words, not mine.)
The tool that was meant to start a conversation became a form field that killed it.
The Wrong Level
Sitting with that feedback in the Retro, the pattern became hard to ignore. The team wasn't just venting. They were pointing at a structural problem:
The User Story was being applied at the wrong level.
On the Sprint Goal level, the User Story made perfect sense. That conversation with the Product Owner and the stakeholders was genuinely useful. Who is this for? What do they get out of it? Why does it matter? Everyone left understanding what the Sprint was about and who it served. The agreed solution got confirmed with the agreed need of the customer.
But on the individual ticket? The why was already answered. The ticket’s existed to fulfill the Sprint Goal. The developer didn't need to reinvent the customer justification for every effort. They needed to know: What exactly needs to happen? What's the situation? What's the expected result? How do we know it's done? What competence is needed?
That's a completely different conversation. And it needs a completely different format.
What We Changed
In that same Retro, we made a decision. With no long debates, no crazy voting needed, no "let's revisit this next Sprint." The entire team agreed immediately. Product Owner included:
From now on, the User Story lives only in the Sprint Goal. Not on individual effort tickets.
Important: this wasn't about getting rid of the User Story. It was about moving it to where it actually works. For the Sprint Goal, we'd write the User Story together with the Product Owner: who is this for, what do they want to do, why do they want it? That conversation didn't disappear. It got stronger, because it happened at the right level with the right people.
For individual effort tickets, we switched to something simpler and more honest. We focused on: What is the situation? What needs to happen? What is the final outcome? Turns out, that format already has a name! It's called a Job Story, and it comes from the Jobs to be Done framework (Alan Klement, later refined at Intercom). Instead of "As a [persona], I want..." it asks: "When [situation], I want to [action], so I can [outcome]." It shifts the focus from a persona to the context. Not who wants something, but what triggered the need and what done looks like.
A context-driven alternative from the Jobs to be Done framework, designed for effort-level clarity.
Over time, I adapted that further. What was still missing for the teams was: who actually needs to do this? On effort tickets, knowing the required competence matters. So the format became:
Not a customer persona, but the executing role. A developer, a tester, a designer. The who answers a different question here: not who wants something, but who needs to act. That made it faster for teams to identify the right person for the ticket during refinement.
What we built from real team feedback — when the first question isn't the situation, but who needs to act.
Each of these three formats has its place. The User Story lives on the goal level, where the customer conversation happens. The Job Story and its adaptation live on the effort ticket, where clarity for the people doing the work matters. It has a purpose within the Sprint Goal, and that's enough. No more pretending and inventing.
The effect was immediate. Refinement got shorter. The conversations about customer value actually got better, because they happened once, at the right level, with the right depth, instead of being diluted across thirty tickets where half the stories' benefit points were made up.
With every team since that one, I've brought this question into the room. And the reaction tends to be similar: relief. Often followed by "why didn't anyone tell us this was an option?!"
The Missing Conversation
After that Retro, the digging started. Was anyone else saying this? The Atlassian page. Scrum.org. Jeff Patton. Mike Cohn. Blog after blog. Other Scrum Masters and Agile Coaches.
Nobody seemed to be making this particular distinction: the User Story belongs on the increment/sprint goal level, not on every effort ticket. Maybe it's discussed somewhere I haven't found. But in the circles I was moving in, the conversation just wasn't happening.
Atlassian defines the Story Issue Type as the "smallest unit of work." The Scrum Guide says nothing about User Stories at all, but everyone assumes it does. Coaches teach teams to put the template on every PBI because that's how they learned it. Nobody stops to ask:
“Does this actually help at this level? Or are we just filling in a form field?”
Even Scrum.org admits that User Stories aren't mandatory. But they don't take the next step. They don't say where the User Story actually belongs, or what to do instead on the ticket level.
It's a gap. And it might be costing teams hours of unnecessary refinement every week.
In A Nutshell
The separation that came out of that Retro became a structural principle that's shown up in other teams since.
On the level where you cut real, deliverable value for the customer, you write the User Story. On the goal level.
Because the User Story never contains a solution. It starts a conversation about value.
On the individual effort ticket refinement, you're talking to the person doing the work. They need clarity, not customer philosophy.
Two levels, two different conversations that need to happen.
Next time you're in a Refinement session and someone is struggling with the User Story on an effort ticket, ask yourself:
Has the conversation about customer value already happened? At the Sprint Goal, at the increment level, at the Slice? If yes, then why are you asking the team to re-justify it on every single effort ticket?
And if developers are sighing at the User Story field: that might be a signal worth paying attention to. Not because every frustration contains a methodological insight. But because sometimes the format is fine, it's just being asked to do a job it was never designed for.
One thing to be careful about: this is not "let's just ditch the User Story." If you remove it from the ticket but don't have it living somewhere else, on the Sprint Goal, on the increment, you've lost the customer conversation entirely. The point isn't to get rid of it. The point is to make sure it happens where it actually matters.
The question is always the same: is the conversation happening at the right level? And if not, what would change if it did?
Feeling like I should have a listen to your team? Book a free discovery call and let's figure out where the real listening should happen: