Do Product Owners Write User Stories?

Is the Product Owner the only one in charge of user stories? Get the inside scoop on who does what when it comes to backlog items.

Published

Do Product Owners write user stories?

It’s a good question, and one that comes up every now and then in newly formed Scrum Teams.

When in doubt, look to the Scrum Guide. And the Scrum Guide, in its 2020 revision, clearly states that the Product Owner is the member of the Scrum Team accountable for creating, communicating, and ordering backlog items.

In other words, it’s the responsibility of the Product Owner to ensure that the Developers on the team have a clear understanding of what they are working on and why it’s important.

Maybe that’s why most Scrum Teams work this way. The Product Owner is the one who user stories and acceptance criteria, articulates the value of these stories to the Developers on the team, and owns the prioritization of the backlog both before, during, and after sprints.

Why do most teams rely on the Product Owner to write the user stories?

First and foremost, the Product Owner is the voice of the customer. They are the ones who have the most direct connection to the end users and understand their needs, wants, and pain points. As such, they are in the best position to write user stories that accurately reflect the value that the functionality in question is supposed to deliver.

The Product Owner also plays a vital role in backlog management. They are responsible for ensuring that the backlog is always ordered in the most effective way possible. This means that the most valuable items — however value is defined — are always at the top, and that the team is always working on the stories that will deliver the most value to the end users.

By writing the user stories themselves, the Product Owner is able to make swift decisions about the backlog, and is able to make sure that it always aligns with the overall product vision and goals.

This isn’t a one-time task. The Product Owner should be constantly reviewing, refining and re-prioritizing the backlog. They should be continuously looking for ways to improve the user stories and acceptance criteria, and to ensure that the team is always clear on what matters and what value it entails.

But here’s the thing: Should the Product Owner be the only one writing product backlog items?

The answer is a resounding no.

See, the developers on the team also have a responsibility when it comes to writing and editing backlog items. Notice the words I’m using; I’m about backlog items and not user stories, and for good reason.

While the Product Owner is responsible for writing user stories and acceptance criteria, the developers on the team are responsible for writing technical backlog items, such as spikes, tasks, and subtasks. These items are necessary in order for the team to experiment and deliver on the user stories themselves.

In many teams, the Product Owner works closely with the Quality Assurance person to make sure that the acceptance criteria are testable. And if the team has a Solution Architect on board, it’s not uncommon for them to also write out the technical side of epics and user stories alongside the Product Owner.

Scrum, as they say, is a team sport.

The Product Owner is the “voice of the customer” and is responsible for defining the problem to solve, but the Development Team is responsible for finding the best solution to that problem. And the whole team is responsible for delivering a working product at the end of each sprint.

In that way, it’s not just the Product Owner who should be writing and editing backlog items, but also the whole team contributing and working together to refine and improve the items on the backlog in question. In a way, although the Product Owner has the final say on what goes into the backlog and in what order, they shouldn’t be the only one making decisions for the items on the backlog.

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.