How will handle multiple users in a user story

Question

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 ?

Answer 1

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.

Answer 2

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.

Answer 3

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

Answer 4

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