Who should write the user stories if not the Product Owner?

I think we can all agree user stories are not part of Scrum but a technique that may be used by team's within the Scrum Framework. If we look at where user stories originated and why they were initially used then we may be able to get some insight into this debate. 

They came from XP as a way for a development team to quickly create a placeholder for a conversation while keeping the user at the forefront. Without going back to the story and collaborating for further details between the business (maybe a PO if they're doing Scrum) and the development team the user stories aren't much use. 

To me, the creation of user stories should be a collaborative effort between the Product Owner and the Development Team. 

As far as who actually writes out the user stories...it could go either way. The Product Owner can delegate responsibility elsewhere but is ultimately accountable. If they leave it to the Development Team to write it out and do not collaborate with them on things like acceptance criteria then they're probably going to end up building the wrong product. 

If I were the PO I'd work with my Development Team to create a process that is understood and transparent for all of us. 

Just another thought on this... If the responsibility of 'writing' user stories is placed on a PO, Dev Team, or Scrum Master by management what impact might that have on their ability to self organize? 

This goes back to my original thought around the Scrum Team being able to self organize around a process that works best for them. 

So, if that is the case, then those user stories should've already been written and in place for the discussion to happen.

What are your thoughts about a user story being the “placeholder for a conversation” which Tony describes? What do you mean by “already written”? Shouldn’t the Scrum Team collectively author the evolving narrative?

What are your thoughts about a user story being the “placeholder for a conversation”

Shouldn’t the Scrum Team collectively author the evolving narrative?

@Ian Mitchell, I consider that is perfectly fine. In fact it is to have a future conversation, a collaborative effort between the PO and the Dev Team and to get more clarity and detail. Who actually ends up adding the detail (writing) during this discussion doesn't really matter according to me. Perhaps rotating the opportunity amongst team members every refinement session may be a good practice. Therefore, anyone from the Scrum Team can author it and it makes no difference in my opinion.

What do you mean by “already written”?

Who puts the placeholder (the user story) into the Product Backlog in the first place i.e. writing it, so that it can be collectively discussed during refinement? Also, I am not talking from the perspective of a Dev Team member identifying new work that may emerge during a Sprint and adding that to the Product Backlog or adding a Technical Debt item, after informing the PO. Similarly, due to feedback from the Sprint Review.

What I am referring to is the new work, the ones that may have come directly from the customer or the market to the PO, the ones that may have not yet been discussed with the Dev Team that the PO wants to achieve through the Dev Team each Sprint. For that discussion and goal setting, those placeholders (user stories) should be there (already written) before a refinement session or else it might just be a poorly planned meeting and perhaps a waste of time in my opinion. 

Also, the statement that was made was "the Product Owner should be the last person to write user stories" which kinda says it would be last thing the PO would do instead of promoting the culture of whoever can at the given moment.

The most effective process I've seen so far involved the Product Owner having a triage process to sort out new ideas and work prior to adding anything to the Product Backlog.

Once they felt they had enough information to have a conversation with the Development Team during Refinement then the work was added to the appropriate place on the Backlog. Typically more acceptance criteria was added or clarified at that point.

There were also times where PBI's were thrown out after feasibility discussions with the Development Team or stories were split in order to implement the more valuable pieces earlier. 

This kept the Backlog lean without cluttering it with every idea that came across their desk. 

Once they felt they had enough information to have a conversation with the Development Team during Refinement then the work was added to the appropriate place on the Backlog.

@Tony Divel, From this sentence, could you clarify who added and what added means? (added = wrote or added != wrote)  What did the who of the previous question add? How was it represented?

Once they felt they had enough information to have a conversation with the Development Team during Refinement then the work was added to the appropriate place on the Backlog.

@Tony Divel, From this sentence, could you clarify who added and what added means? (added = wrote or added != wrote)  What did the who of the previous question add? How was it represented?

In the scenario I'm describing, the Product Owner is typically writing the initial story and adding it to the backlog. The Development Team may contribute to it and edit it as needed to refine it to a ready for Sprint state. 

Adding would be described as making the work transparent on the Product Backlog. Could be adding a Sticky Note or a Story in a tool if that's being used. 

I'd still recommend establishing a process. It may not always be optimal to only have the Product Owner write or add stories, however, the Product Owner should have input and be aware of what's being added to the backlog. 

For example. 

One product I worked on had submissions from operations, other business units, senior leadership, audit, and development. We established a triage process so anyone could submit requests for work to be added to the Product Backlog. The PO would sift through it, gather more information, modify it to fit a user story if applicable, and move it to the Product Backlog to be refined if needed. This saved the Development Team from having to refine work that may never be worked on and kept the focus on the high value items. 

Note: This example was for a more mature product that had market fit and was focused on enhancements and future growth. 

When launching a new Product something like this may not make the most sense.

In the scenario I'm describing, the Product Owner is typically writing the initial story and adding it to the backlog. The Development Team may contribute to it and edit it as needed to refine it to a ready for Sprint state. 

@Tony Divel, This is precisely where I was coming from. The debate was around the line which I have highlighted in bold. There might not be a simple answer to who writes a user story or a PBI, but the common occurrence is the PO being the one to initially add it, write it, whatever.

Adding would be described as making the work transparent on the Product Backlog. Could be adding a Sticky Note or a Story in a tool if that's being used. 

Irrespective of where it is added, sticky on a wall, or story in a tool, something needs to be written in both cases (it can't be blank), and who writes this was the argument. And here too, I am going to assume PO, however, bear in mind I am not saying others can't. As in the case above it depends on the situation.

I'd still recommend establishing a process. It may not always be optimal to only have the Product Owner write or add stories, however, the Product Owner should have input and be aware of what's being added to the backlog. 

I 100% agree, it should not be that the PO becomes the point of failure. In certain cases, as I discussed above, the Dev Team by virtue of delegation from the PO, can add items that may emerge, technical debt etc, and after discussing with the PO. In these cases it may be apt to say there is no mandatory rule that ONLY the PO should write it. I think in this scenario whoever brings up the work can write it and thereby add it to the product backlog.

Once again, my reason for this post was to understand why this statement was made "the Product Owner should be the last person to write user stories and that it is a highly misunderstood concept that the Product Owner should be the one writing user stories."

Agree with you there. This discussion illustrates the importance of making whatever process is used transparent and understood by those involved.

In regards to the statement you came across, I don't think the Product Owner should be the only or the last person to write user stories. 

Good conversation. Hope you don't mind if I chime in.

The Scrum Guide states the Product Owner is responsible for the items in the Product Backlog but never does it say that they are the only one to introduce items.  In my teams that I view as successful, introducing placeholders into the Product Backlog could and was done by anyone in the organization.  The Product Owner would then spend time investigating the item by talking to the originator. As information is gained other individuals are included in discussions. "Other individuals" could be other people submitting similar items, developers to provide some technical knowledge or even other Product Owners to identify if there supplemental items that could be added to other Product Backlogs. The result of all of this effort goes into "filling out the story".  To me this is what transparency, refinement and self-organization is all about.

@Steve Vb I enjoy your questions.  They always provide some great conversation and debate.

 I enjoy your questions.  They always provide some great conversation and debate.

@Daniel Wilhite, Thank you! :)

Who puts the placeholder (the user story) into the Product Backlog in the first place i.e. writing it, so that it can be collectively discussed during refinement?

I'd suggest that the matter might fall under those Scrum Guide responsibilities where "The Product Owner may do the above work, or have the Development Team do it.". I don't think it is possible to be more prescriptive than that.