In agile design/development, who writes the user stories and what is the process? Should UX researchers do their research first in order to help define better user stories?
In my current project, we have user stories, but UX has not been involved in user research to help define those stories. This has taken us down some inefficient paths with the project. I'm not experienced with UX strategy, but it seems a wise approach would be to base user stories on upfront UX research. Yes? No?
As pointed out by Austin French's answer, the story writing typically is the responsibility of the Product Owner (PO) in "normal" agile. And in some projects, it's not uncommon for the PO to work with a technical lead to help define the stories so that it is easier for them to be translated into actionable work.
As the question implies, where UX is involved you can't/shouldn't have the PO writing stories that also define UX. If they do, they are essentially defining implementation, which is not the job of the story.
Take for example the example story quoted in another answer...
We need a grid to show Customer Details
The problem with this story is that it's both defining a feature (show customer details) and a UX implementation (a grid).
The story from the PO should be...
We need to show Customer Details
Now it's up to the developers to decide the "how". And the UX designer is the one to decide how the Customer Details should be shown.
That said, you can decide whether you want to treat the UX designer as one of the development team (implementer of stories), or as one of the leads (guider of stories).
UX Designer as Development Team Member
In this approach, the UX designer is one of the developers. Just as a development team might have a database specialist who's taking care of the data portion of stories, the UX designer is taking care of the UX portion of the stories.
UX Designer as Technical Lead
In some agile approaches though, the technical leads will meet with the PO to help define the stories, which then will be passed on to the development team. And with this approach, one might treat the UX designer as one of the leads. The UX designer might have a specific approach to the product in mind that directly influences the stories.
The truth is, whether the PO means to or not they will subconsciously be imagining the UX in their head as they create stories. They will inadvertently influence the UX direction whether they mean to or not. And this is why having them work with a UX designer to help craft the stories can help immensely.
Conclusions
Generally, and I say this generically as your process and mileage may vary:
Perhaps a requirement is:
We need a grid to show Customer Details
Ideally, this will be groomed. Where a lead, the PO and stakeholders who are in the process can look at the requirements and define something more workable:
We need a grid, that is suitable for Mobile, and shows Customer Name, Email, and exandable box with address, which is editable on the click of an edit icon
Assuming this is considered workable and put into the backlog. Then during the Sprint Planning the team should be able to identify complexity and requirements that aren't known. A possible problem might be:
We do not have a grid framework that we know can do all of this.
If so, what we have done is create a spike for a POC if the task feels too big and unknown.
We want to use Angular's Material Grid, but we can't be sure if this is 3 points, 21, or impossible without a ton of hacking.
Assuming that isn't the case, and the team can agree on complexity, then it gets slotted in to the sprint.
4b. If that isn't the case, then slot the spike into the POC, along with review or demo. And do the actual work in a future sprint.
In my various experiences (Full Stack), any unknown adds a ton of risk. A ton of risk / unknowns means more points. The challenge of course is generally organizations who aren't really Agile, and so delaying work for a Spike isn't possible. With a good scrum master and a few successful sprints though, it becomes easier when the team can confidently say:
We are realistic in our estimates, and our successful Sprints and rapid delivery are because of the process.
I would second Ren's answer in that anyone can write a user story and it's the PO's job to prioritise them.
I think your question should be who is involved with story refinement. This is the process is getting a story to meet you DoR (Definition of Ready).
Depending on how you work, ready may mean many things, but if the story impacts on UX in some way then the UX resource should have input into the refinement.
It's very common for a story to enter the backlog, enter refinement and then end up with so many unknowns that the development team can't start work. It's also common for a story to enter the backlog with so many unknowns that a UX designer cannot proceed either.
This for me is where UX comes into its own, picking up those stories, engaging with the various stakeholders and getting the answers to the unknowns and getting stories ready to work on.
It may just be getting answers from PO (via their stakeholders) or via a BA, or via User Research. But for me, it's the UX responsibility to drive stories forward. If you want to be able to drive the direction of the product, you need to be involved in creating the vision for that product, which means as Tim says, being involved in the authoring of the stories either directly or indirectly.
Anyone can write user stories. It's the product owner's responsibility to make sure a product backlog of agile user stories exists, but that doesn’t mean that the product owner is the one who writes them. Over the course of a good agile project, you should expect to have user story examples written by each team member. Also, note that who writes a user story is far less important than who is involved in the discussions of it.
It is difficult to create user stories without any Design Research. There is hardly any understanding about users' expectations and behaviour without such study. Prior to this, the product only exists as the Problem Statement. Only when the core features of the product have been defined, user stories can be created for further design and development.
It would probably be ideal, but often user stories are created as part of an agile development process focused on creating a MVP that can be tested and updated before extensive research is involved. As with most questions here at UXSE, it depends on the context and in this case a YES or NO answer can be equally valid. Remember that you are allowed to make assumptions as long as you go and validate them.
Also, in an ideal world anybody should be able to write the user story. It indicates a mature team with experience in agile and user-centred design processes. However, in the case where you team has a different level of design/development maturity, usually the person with the most experience drives this process, be it the product owner, UX designer/lead, Dev lead or anyone else.
