3

I thought this would be a more common problem, but I'm having trouble finding anything that provides a solution for me.

I currently have a user story that has 2 users/roles. I am wondering if there is a best practice solution to split that story, noting that writing user stories is an art and not a science.

Scenario: - There are two external user types - sellers and buyers. - Both sellers and buyers want to view details of upcoming exhibitions (for various reasons, such as the buyer wants to buy/research, and the seller may want to research - if they were selling they would already be aware of the exhibition).

Current Story: AS A seller OR A buyer I WANT to view details (location/date/time) of upcoming exhibitions SO THAT I can attend the exhibition.

Is there a way to write a user story for this without generalising the role e.g. "potential exhibition attendee", or creating a 'Job Story' e.g. "WHEN I want to visit an upcoming exhibition, I WANT TO view the location/date/time of the exhibition, SO I CAN attend the exhibition:. For this scenario, even if I split the story the most simple solution really is the same: List upcoming exhibitions somewhere on the public-facing site, and provide details about location/date/time.

OR should I be generalising the two identified user roles (sellers and buyers) for this particular story, OR using a mix of User Stories and Job Stories in my backlog...

Thoughts/comments/suggestions? :)

EDIT: I'm also having the same problem with searching user stories... I have a user story related to being able to search products by product name, however, this is a need for multiple user types i.e. buyers and sellers.

5

You seem to have already answered your own question:

Scenario: - There are two external user types - sellers and buyers.

From this, I infer that you have other roles that are considered internal (e.g. exhibition host, application admin, ...). You inherently listed buyer/seller as "the external user types", because that is what separates them from the other user roles (as per my inference).

Assuming my inference is correct, the correct approach here is to the define "external" and "internal" user roles (in a dictionary, if you don't already have one), and then you can refer to them where relevant.

AS AN external user
I WANT to view details (location/date/time) of upcoming exhibitions
SO THAT I can attend the exhibition.

To generalize the approach: if you need to refer to an abstract concept (in this case a grouping of roles), it becomes necessary to name the abstract concept so that you can then refer to it without worrying about it being understood.
Rather than trying to cleverly find a roundabout way to make it implicitly understood, keep it simple and make it explicitly understood (by explicitly defining the concept).

| improve this answer | |
3

How you split the story depends on the sizing of the story. I see two possible options.

The first option, and where I would start, would be to write your story in a way that encompasses both user types. An example could be "As a potential exhibition attendee, I want to view the event details of upcoming exhibitions so that I can attend the exhibition." I would then use acceptance criteria to define who the potential exhibition attendees are, ideally mapped to specific users roles or personas. I would also use acceptance criteria to identify what, exactly, is meant by event details to clarify location and date and time. This is what I would initially present to the team.

Based on refinement of this, the team may come up with questions or concerns. If there is a lot of similarity between how the different user types are handled, maybe it makes sense to not split the story up. However, if there's unique work that needs to be done, maybe it makes more sense to split it up by user type or some other method to have smaller stories that can be delivered and reviewed.

As far as format, expressing the need as a user story, job story, use case doesn't matter so much. Your product manager or development team may find one format preferable. But that's a discussion for the team to ensure that the user need is expressed in a way that works for everyone involved. The same idea applies, though - the team can evaluate different ways to split up the story if it's necessary based on their evaluation of it.

| improve this answer | |
0

The answer could be different in different individual cases, so let's look to the purpose of a user story for your answer.

The user story was created in response to robust specification documents that were meant to be cleanly handed off and avoid any need for further conversation or clarification. Instead, a user story was intended to give just enough information to facilitate a conversation between the team and the user. The answer to your question could be: "Which option facilitates a better conversation?"

If it really applies exactly the same for every attendee, then you can generalize. Alternatively, perhaps during refinement, you, the dev team, and stakeholders ask the question "How is this different if the user is the buyer? or the seller?"

And one last thing: the form of "As a, I want, So That" is not required for user stories. Would another format work better for your conversation?

| improve this answer | |
0

Your case is that several roles share the same need and want the same feature:

  • either use a more general role that covers the common interests (the advantage is that generalization encourage to think in broader terms and could thus identify other interested user populations)
  • or simply enumerate the relevant roles, like you did it very pragmatically in your question (the advantage of remaining concrete is that you can rely on well identified personas and do not risk to invent some abstract role nobody can really identify with).

A more delicate case is when different users have different needs (sometimes conflicting) for the same feature. In practice:

  • if the stories are complementary and not contradicting, handle them as any other stories: just keep 2 independent stories in the backlog (iterative refinement of the feature in due time).
  • if the stories are contradicting, keep in mind that a user story is only a placeholder for a discussion. Resolve the conflict by discussing with both parties (together of possible) and agree on a common ground. Go back to the first case.
  • if there is an overlap, merge them or make them independent using the same techniques as above. If one story appears to be not a real user story but a desire about how stories of other users should be, then consider making it an acceptance criteria.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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