Who Should Actually Write User Stories? PM, PO, or Devs?

Here’s the uncomfortable truth:
If only one role “owns” writing user stories, your backlog is already in trouble.

I’ve coached dozens of teams where:

PMs hoard the backlog and throw stories over the wall
Devs refuse to touch stories because “that’s product’s job”
POs obsess over wording instead of outcomes

The result is the same: bloated backlogs, confused developers, rework, and “that’s not what I meant” conversations in every sprint review.

So let’s settle this: who should actually write user stories — PM, PO, or devs?
Short answer: you’re asking the wrong question.

The real question is: who should be responsible for what part of the story?

The Real Job of a User Story (Most Teams Get This Wrong)

Before we argue about who writes them, we need to align on what user stories are for.

A user story is not:

A mini-specification
A contract
A ticket to keep Jira from being empty

A good user story is:

A placeholder for a conversation
A promise of value to a user
A boundary for implementation, not a prescription

When teams treat user stories as documentation instead of conversation, they start optimizing for “who writes them” instead of “how we collaborate around them.”

That’s where roles get territorial and quality tanks.

Who Thinks They Should Write Stories (and Why They’re Wrong)

Product Managers: “I Own the Customer, So I Own the Stories”

Typical PM mindset:

“I talk to users, so I know what needs to be built.”
“I’ll write all the stories and acceptance criteria, then dev just implements.”

Problems this causes:

Stories are written in solution-speak (“Add a dropdown…”) instead of problem-speak (“User needs to quickly filter…”)
Devs feel like code monkeys, not problem solvers
PM becomes a bottleneck; backlog refinement dies when PM is overloaded

Product Owners: “Writing Stories Is Literally My Job”

Scrum literature doesn’t help here. Many POs interpret “owns the Product Backlog” as “must type every story personally.”

What happens:

PO spends hours wordsmithing stories instead of talking to users or stakeholders
Team learns to wait passively for “ready” stories
Refinement becomes a one-way broadcast, not a collaborative design session

Developers: “We’ll Write Technical Tasks, You Handle Stories”

Many devs opt out of story writing:

“We’re not close to the customer.”
“We’ll just break down the work once the story is ready.”

Issues that follow:

Stories lack technical reality (performance, security, edge cases)
Estimation is wild because unknowns hide behind vague wording
Devs complain stories are unclear, but never help clarify them

If any of these sound like your team, you don’t have a story-writing problem. You have a collaboration problem.

The Opinionated Answer: Story Writing Is a Team Sport (With Clear Roles)

Here’s the stance:
User stories should be co-created. Different roles own different parts.

Think of it like this:

PM/PO owns the “Why” and “Who”
Team (including devs, QA, UX) owns the “How” and “What Exactly”
Everyone owns “Is this clear and valuable?”

Let’s break it down.

What PMs / POs Should Own

PMs/POs should be primarily responsible for:

Framing the problem and outcome
- “What user problem are we solving?”
- “How will we know it’s successful?”
Prioritization
- What gets done first, and why
Connecting to strategy
- How this story ladders up to product goals

Example:

As a returning customer, I want to see my last 5 orders so that I can quickly reorder frequent items.

The PM/PO should be able to clearly explain:

Who is the “returning customer” persona?
Why “last 5 orders” and not full history?
What metric improves if we ship this? (e.g., repeat purchase rate +5%)

What Developers (and QA, UX) Should Own

The dev team should be responsible for:

Clarifying feasibility and constraints
- “We can’t show last 5 orders in real time without caching.”
Identifying edge cases
- “What about guest checkout? What if an order is pending?”
Defining implementation-level tasks
- API changes, DB migrations, UI components, test coverage

They should be actively involved in:

Writing or refining acceptance criteria
Breaking stories into technical tasks
Challenging assumptions: “Is this the simplest thing that could work?”

What Should Be Done Together

There are parts of the story that should always be shaped collaboratively, typically in refinement sessions:

Acceptance criteria
Examples and scenarios
Scope boundaries (what’s in, what’s explicitly out)
Dependencies and risks

If your refinement sessions are just the PO reading stories while devs estimate, you’re missing the point. Refinement should feel like designing the work together, not status reading.

A Practical Model: Who Does What, When

Here’s a concrete workflow that works well for high-performing teams:

1. PM/PO Drafts Outcomes, Not Detailed Stories

Before refinement, PM/PO prepares lightweight story placeholders:

A one-line user story in “As a… I want… so that…” format
A short note on business outcome / metric
Links to any relevant discovery notes or user feedback

Example:

As a returning customer, I want to see my last 5 orders so I can quickly reorder frequent items.
Outcome: Increase repeat purchase rate for logged-in users by 5% in 3 months.

No 10-line acceptance criteria yet. Just enough to start a conversation.

2. Team Refinement: Co-Create the Real Story

In refinement (or story mapping) sessions:

PM/PO explains the why and any constraints
Devs, QA, UX ask questions and propose options
Together, you define:
- Acceptance criteria (e.g., using Gherkin-style)
- Edge cases
- What’s out of scope for now

Example acceptance criteria co-created:

User must be logged in
Show up to 5 most recent completed orders
Each order shows date, total amount, and “Reorder” button
If no past orders, show helpful empty state message

The typing can be done by whoever is fastest in Jira/your tool. That’s not the important part. The conversation is.

3. Devs Break Down into Technical Tasks

Once the story is understood and agreed:

Devs create subtasks:
- Backend: Add /orders/recent endpoint
- Frontend: “Recent orders” component
- DB: Index on user_id, order_date
- QA: Test plan + regression tests
Devs may add technical acceptance criteria:
- Response time < 300ms for 95th percentile
- Works on mobile and desktop

Now the story is a shared artifact, not a PM or PO artifact.

Common Mistakes (What Not to Do)

1. “PO Must Write Everything” Syndrome

Symptoms:

PO spends half their week in Jira
Stories are “perfectly written” but poorly understood
Devs complain stories are unclear but never join discovery

Why it’s harmful:

You optimize for documentation quality, not shared understanding
PO becomes a single point of failure. When they’re out, refinement stops

2. Devs Checking Out of Story Creation

Symptoms:

Devs show up to refinement, estimate, and move on
Questions surface only after the sprint starts
Stories get blocked mid-sprint due to “unknowns”

Why it’s harmful:

You discover constraints too late
You lose chances to simplify or improve solutions early

3. Over-Specifying Stories

Symptoms:

Stories read like waterfall specs:
- “The button shall be blue (#0055FF), 14px, bold, top right…”
No room for dev creativity or UX input
Every small change requires story rewrites

Why it’s harmful:

You turn stories into requirements contracts
You kill team ownership and innovation

4. Using Stories as a Blame Tool

Symptoms:

“It was in the story, you should have read it”
Stories become a CYA mechanism
Retrospectives devolve into “who wrote this story?”

Why it’s harmful:

You incentivize covering yourself, not collaborating
Psychological safety drops, learning stops

How to Fix Your Story Workflow: Concrete Steps

Here’s a tactical way to shift from “Who writes?” to “How we collaborate?”

1. Redefine “Ready” for Your Stories

Stop treating “written by PO” as the definition of ready.

Create a Definition of Ready that includes:

Business value and outcome are clear (PO/PM)
Story has been discussed in refinement with dev + QA
Acceptance criteria are co-created and understood
Dependencies and major risks identified
Story is small enough to complete within one sprint

If a story hasn’t been talked through, it’s not ready — no matter how nicely it’s written.

2. Timebox Story Drafting

PMs/POs: don’t spend hours polishing stories in isolation.

Try this rule:

Max 5–10 minutes drafting a story placeholder
Save the details for live refinement

This forces you to bring the team into the thinking, instead of trying to predict every detail alone.

In refinement:

Share your screen with the story open
Type acceptance criteria live as people speak
Ask devs and QA:
- “What edge cases are we missing?”
- “What’s the simplest version that still delivers value?”
- “What worries you about this story?”

You’re not “reviewing stories.” You’re designing work together.

4. Rotate Who Types, Keep Who Decides

To break the “PO must write everything” pattern:

Let devs or QA drive the keyboard during refinement
PO/PM still owns:
- Priority
- Value framing
- Scope trade-offs

This reinforces that the backlog is a team artifact, not a PO diary.

5. Track One Simple Metric: “Clarification Churn”

For a couple of sprints, track:

How many stories needed major clarification after the sprint started?
How many stories were blocked due to unclear requirements?

If more than ~10–15% of stories per sprint fall into this bucket, you’re not collaborating enough on story creation.

Use this data in retrospectives to improve how you write and refine stories.

Real-World Pain Points (and How This Approach Fixes Them)

Pain Point 1: “We Keep Building the Wrong Thing”

Cause:

Stories are written by PM/PO in isolation
Devs don’t understand the real user problem

Fix:

PM/PO frames problem and outcome
Team helps shape solution in refinement
Everyone can answer: “What user problem are we solving?” in one sentence

Pain Point 2: “Our Estimates Are Always Off”

Cause:

Devs see stories for the first time during estimation
Technical risks and unknowns are discovered mid-sprint

Fix:

Devs actively participate in story shaping
Edge cases and constraints surface early
Stories get right-sized before they’re committed to a sprint

Pain Point 3: “Our Backlog Is a Graveyard”

Cause:

PM/PO endlessly writes stories that never get discussed
No shared ownership of what’s in the backlog

Fix:

Use story placeholders, not full specs
Don’t fully flesh out stories until they’re near the top
Make refinement a regular, collaborative event

Tools Can Help, But They Don’t Replace Conversations

Use tools to support collaboration, not to avoid it.

Use Jira (or similar) for tracking and linking stories to epics and metrics
Use virtual whiteboards for story mapping and discovery
Use planning poker tools to drive discussion about complexity, not just numbers

For example, a tool like ScrumPoi lets teams run quick, anonymous planning poker and retrospectives without signups or per-user costs, which makes it easier to get honest input from everyone — not just the loudest voice in the room.

But remember: tools amplify your process. If your process is “one person writes, everyone else obeys,” no tool will fix that.

Conclusion: Stop Asking “Who Writes?” and Start Asking “How Do We Think Together?”

If your team is arguing about whether PMs, POs, or devs should write user stories, you’re focusing on the wrong thing.

The healthy pattern looks like this:

PM/PO: Owns value, outcome, and priority
Team (dev, QA, UX): Owns feasibility, details, and implementation
Everyone: Owns clarity and shared understanding

User stories are not a writing contest. They’re a collaboration habit.

If you walk into refinement and see one person talking and everyone else passively nodding, you don’t need better stories — you need a better way of working.

Start there. The words in Jira will follow.

Who Should Actually Write User Stories? PM, PO, or Devs?