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?

5 Answers 5


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.


  • The PO should not be defining UX (consciously or sub-consciously)
  • The UX designer is a "developer" just like a database lead or a software engineer
  • UX may actually be a driving force behind design and stories, and as such could/should be part of the story authoring process
  • For some further reading, the Nielsen Norman Group has some good reading on this topic. See nngroup.com/articles/agile-not-easy-ux for example.
    – Tim Holt
    Commented Mar 11, 2020 at 16:41
  • So maybe the issue I'm having is (partially) not who is writing the stories but how they're worded. Our stories are often written exactly like what you quoted. "As a [blank], I want [blank], so that [blank]." And then we're told to go design the blanks. I'd rather focus on the "so that..." to better understand what the user is trying to accomplish and help come up with the best solution for that. Instead we take their stories verbatim and are expected to design that solution.
    – MRL
    Commented Mar 12, 2020 at 19:56
  • The UX member(s) as the driving force behind stories is better understood in the context of features, which are owned by Product Management. UX is often part of or has an informal connection to Product Management.
    – Benjamin S
    Commented Mar 13, 2020 at 15:35

Generally, and I say this generically as your process and mileage may vary:

  1. The Product Owner should have the requirements:

Perhaps a requirement is:

We need a grid to show Customer Details

  1. 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

  2. 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.

  1. 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.

  • 1
    This doesn't answer the question. User stories come before the design and development process. So they don't describe that the data should be presented in a grid. User stories describe - with a lot of surrounding context - why the user wants to view the data on a mobile device for example.
    – jazZRo
    Commented Mar 11, 2020 at 9:38
  • @jazZRo, yes you are correct. my point was supposed to mirror Ren's answer, but I guess I lost the answer in my longer than expected answer. Commented Mar 11, 2020 at 12:14

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.

  • +1 good reference but it would be nice to see some of your own ideas in addition to what you have referenced :)
    – Michael Lai
    Commented Mar 11, 2020 at 22:51
  • "Anyone can write user stories" is one interpretation of Agile. In some teams, only the PO gets to do that, in others it's team oriented. Sometimes to the extreme that the team is also the PO.
    – Tim Holt
    Commented Mar 12, 2020 at 3:28
  • 1
    @MichaelLai Thanks Michael. I have added my views on the subject.
    – Ren
    Commented Mar 13, 2020 at 8:21
  • Do you think the person with the best understanding of the client or user requirement (since they might not be the same group of people) that should be writing the user stories? I would like to think that if the product owner has a good understanding of user-centred design then yes, but if not then I would be a bit hesitant about it...
    – Michael Lai
    Commented Mar 15, 2020 at 22:56
  • Ah, right. I was picturing both the requirements as a whole. I should have simply mentioned them as Product Requirements. So... in a situation where a project has yet to carry out Design Research, the product is really in a nascent state with only the core idea of its purpose. There is really no way to create User Stories at that stage. User stories will most likely happen after there is good clarity on the product features and its users.
    – Ren
    Commented Mar 18, 2020 at 11:53

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.