I am trying to understand the role of multiple users in a user story. There is a chance that a particular feature will behave differently depends on the role of users. Let me try to clarify the question with an example we are planning an implementation of validation messages when creating a trade order. But these messages will be applicable depends on each user roles, say trader, administrator, advisor.

  • As a trader, i will get a warning message when adding invalid orders so that the invalid order can be reviewed and edited by trader in trade depository
  • As an advisor, i will not be able to add invalid orders with a warning message so that the advisor is not able to commit any invalid orders to trade depository

So the question is Should we create separate user stories for each user roles or can we accommodate this in one story ?

  • This is really a question about decomposition and refactoring. Please provide some real examples of each (obviously with any sensitive information redacted) so that we can better gauge the similarities and differences between the stories.
    – Todd A. Jacobs
    Commented Oct 11, 2018 at 13:48
  • @ToddA.Jacobs, i have included some examples. Please check Commented Oct 12, 2018 at 13:17
  • 1
    So you allow traders to add invalid orders, as long as they get a warning? But advisors can't? Why? Regardless, you're missing a context phrase or value proposition for each story. "I want foo so that bar" really helps to clarify the point of a story.
    – Todd A. Jacobs
    Commented Oct 12, 2018 at 13:33
  • @ToddA.Jacobs User permission is different for the advisor and trader. So the validation messages will also change as per the role Commented Oct 15, 2018 at 7:55
  • Then you’ve answered your own question. If you have different actors with different use cases, then you need different user stories.
    – Todd A. Jacobs
    Commented Oct 15, 2018 at 13:42

4 Answers 4


As others are pointing out - there are multiple ways to handle something this. My personal approach is to create a business level user story like:

-- Begin User Story

User Story: As a trader or adviser invalid orders are handled

Acceptance Criteria: Given that I am a trader when I make an invalid order then I am presented a warning message

Given that I am an adviser when want to make an invalid order then I am prevented from doing so

Given that I am the Trader System [or whatever name you choose for the 'computer actions'] when an invalid trade is attempted then I log the action

--- End User Story

Essentially - if there is truly one one thing that rises to a user story level ('invalid trades' in this case) then I will have multiple acceptance criteria across roles. The challenge with this approach is that it would potentially make something like story mapping and shuffling user stories a little bit more difficult - since you will likely want to group roles together. So - moving this particular story around as part of a story mapping exercise could be hindered if you are looking to separate the roles in the overall story mapping exercise.

Finally - I would point out that while the user story that I presented here was a 'business level' user story, the dev team may choose to create individual tasks to accomplish that story. In this case, one approach could be to create one task for the trader role and one for the analyst. And - those tasks could potentially implemented by separate folks in separate sprints.

  • 1
    I think it would be possible, maybe advisable, that the PO and Team would agree - especially if the Story has quite a high estimate as it stands - to split this and create separate User Stories (for Trader and Adviser). That improves traceability, makes it more likely that one of those User Stories can be completed within a Sprint, gives us the option to drop the variant behaviour if the other role is not important enough, and gives a precedent for adding more Users who have special functionality later.
    – AAT
    Commented Oct 12, 2018 at 14:52
  • 1
    BTW we should not talk about Tasks unless we are on the Development Team. And even if a User Story is implemented as multiple Tasks, I do not think that means we should split it across multiple Sprints. User Stories must be completed within a Sprint except in (very!) exceptional circumstances.
    – AAT
    Commented Oct 12, 2018 at 14:54
  • 1) In terms of devs owning tasks- I said that in my answer and agree :) "the dev team may choose" (2) On your main point that the discussion to split or combine user stories is highly dependent on the exact environment - also agree. The details provided in the original question were laser focused and sparse - and I tried to frame my answer that "if there is truly only one thing that rises to a user story". That may have not come across clearly in my answer
    – daLegacy
    Commented Oct 12, 2018 at 15:11
  • 1
    I'm not trying to argue against your main point at all -- aiming for clarification and also to put a little more meat on the approach of splitting to more User Stories before the Team takes the work into a Sprint. My point about Tasks is just that we need to keep that in the Team's scope as a detail of how they implement the agreed Stories, again I am just looking to clarify rather than disagree. It's a good answer!
    – AAT
    Commented Oct 12, 2018 at 15:39

Great question, and an answer really depends on business value context. That being said, it's more often than not a good idea to break a piece of functionality into manageable pieces for a development team to understand and implement for a few reasons.

1.) You may find that by breaking the work item down by user, the business value may be different for each user type, which in turn will help understand what pieces of this functionality are more valuable, thus leading to better transparency into which pieces are prioritized first.

2.) Ultimately, the Development Team is responsible for all estimates. Business stakeholders (Product Owners, in Scrum) may influence the Development Team by helping the team understand and select trade-offs, but the people who will perform the work make the final estimate. By breaking down work items, you give your development team a better chance of an accurate estimate, which will help with planning purposes down the line.

  • Clarified my answer to include general stakeholders. Commented Oct 12, 2018 at 13:22

If that's really the only difference, I would write two stories.

I'd pick the highest priority role & write the story for that role.

Then I'd write another story that said,

  As a non-ROLE1 user,
  I want to see an error message in (the situation) that is tuned for my role
  so that (whatever the reason is).

The answer hinges on why those roles need different validation messages.

If that is because actually different validations are performed, consistent with different objectives that each role has, then it makes most sense to create a separate user story for each role.

If it is to rephrase the same validation error in different terms that are best understood by each role, then there is something to say for having it all in one story.

When in doubt, I would start out with multiple stories and then see if the similarities are big enough (and the differences small enough) to justify merging them. The worst that can happen is that after implementing the first story, the developers tell you that doing the others is only five minutes of work (while doing it properly according to the Definition of Done).

  • @Venture2099 While you're making a valid point, it's too close to crossing SE's "be nice" policy and CoC, which prohibit put downs. Please consider making the point again differently. I'll clean up this comment once you flag it "no longer needed."
    – Todd A. Jacobs
    Commented Oct 11, 2018 at 20:26
  • @MarkC.Wallace: Apparently it wasn't clear that I wrote a rhetorical question, so I rephrased. Commented Oct 12, 2018 at 13:28

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.