In Agile product development, user stories are at the heart of how teams capture user needs and translate them into actionable work. But while the format of a user story is fairly standard — “As a [user], I want [goal] so that [value]” — one of the most debated questions is: who actually writes them?

Is it the product manager, the product owner, the business analyst, the developer, or even the customer themselves? The truth is, user stories are not owned by a single role. Instead, they are the product of collaboration. Let’s dive deeper into this question.

1. The Purpose of User Stories

Before answering who writes them, it’s helpful to understand why they exist.

User stories:

• Capture user needs and goals in plain, non-technical language

• Encourage discussion between stakeholders and the team

• Serve as a reminder to refine requirements and add acceptance criteria

• Provide a basis for estimation and prioritization in sprints

A user story isn’t meant to be a rigid requirement; it’s a conversation starter.

2. The Role of the Product Owner (PO)

In Scrum, the Product Owner (PO) is typically responsible for the product backlog. That includes ensuring items (like user stories) are clear, valuable, and prioritized.

• The PO often initiates the writing of user stories.

• They represent the voice of the customer and ensure stories align with business goals.

• They collaborate with stakeholders and the team to refine them into sprint-ready items.

So while the PO usually “owns” the backlog, they are not the sole author of every story.

3. The Role of Product Managers

In organizations where both product managers and product owners exist, the product manager is often responsible for the strategic vision. They may write higher-level epics or feature concepts, which are later broken into smaller user stories by the PO and team.

For example:

• PM defines the business goal: “We need to increase checkout conversion by 10%.”

• PO and team translate this into stories: “As a shopper, I want to check out with one click so that I can complete purchases faster.”

Here, the PM sets direction, while the PO refines execution.

4. The Role of Business Analysts

In some companies, especially outside pure Agile environments, business analysts (BAs) play a significant role in writing user stories. They often:

• Conduct stakeholder interviews

• Translate complex requirements into user-friendly stories

• Add detailed acceptance criteria and edge cases

BAs act as a bridge between business and technical teams, ensuring clarity.

5. The Role of Developers and Engineers

Developers don’t usually create user stories from scratch, but they play a critical role in refining them.

• During backlog grooming, developers clarify technical feasibility.

• They may split large stories into smaller, deliverable units.

• They sometimes propose new stories when technical tasks directly affect user experience (e.g., “As a user, I want faster page load times so I don’t abandon the site.”).

When developers actively contribute, stories become more realistic and estimable.

6. The Role of Designers and UX Researchers

Designers and UX specialists also influence stories:

• They translate usability findings into user needs.

• They propose stories that address accessibility, navigation, or overall experience.

• They ensure stories reflect real user behavior, not just business assumptions.

Example: After usability testing, a UX researcher may add: “As a visually impaired user, I want alt text on images so that I can use a screen reader effectively.”

7. The Role of Customers and Stakeholders

Ultimately, user stories represent the customer’s voice. While customers rarely write them in the formal template, their feedback, surveys, and interviews inspire most stories.

• Stakeholders articulate business goals.

• Customers highlight pain points through support tickets, reviews, or interviews.

• These insights become the raw material for stories, shaped by the product team.

8. A Collaborative Approach: The Three Cs

Agile emphasizes that user stories are about conversation, not documentation. This is captured in the Three Cs model:

1. Card – The written story itself (short and simple).

2. Conversation – The discussions around the story, where details emerge.

3. Confirmation – The acceptance criteria that define “done.”

Because conversation is key, stories work best when multiple roles contribute.

9. Best Practices for Writing User Stories

• Involve the whole team: Don’t isolate story writing to one role.

• Start simple, refine later: Stories don’t need full detail upfront.

• Anchor in user value: Always ask, “Who benefits and why?”

• Keep them small: Large stories should be split into manageable chunks.

• Review often: Use backlog grooming sessions to refine collaboratively.

10. Conclusion: Who Writes User Stories?

So, who writes user stories? The answer is: everyone involved in delivering user value.

• Product Owners usually initiate them.

• Product Managers and Business Analysts provide strategic and detailed input.

• Developers and Designers refine feasibility and usability.

• Customers and stakeholders provide the voice of need.

At the end of the day, a good user story is never written in isolation. It is co-created, refined, and validated through collaboration. This shared responsibility ensures stories remain meaningful, testable, and aligned with both business goals and user needs.

In short, while the Product Owner may hold the pen, the entire Agile team holds the story.