Hi there. Forgive me for a potentially newbish question (I'm just starting out in the world of analysis):
With user stories, I know that it's good practice to give your "As a user..." section a specific role or persona to help explain the context of the user story. I'm currently writing user stories for a system where we have a handful of different roles who all have different viewing/editing permissions throughout the system. Most of these permissions cross over between the roles, so I'm wondering how to approach the user stories. Obviously, I don't want something that looks like:
"As an administrator, team manager or operator, I want to be able to..."
What is the best way to approach this? Do I just repeat the same story for each role? Do I use a generic "As a user with the correct permissions, I want..."?
Currently I have these stories simplified to "As a user, I want..." and then I have a final story that says:
"As the system, I must only allow users to perform actions as defined by their role permissions."
Is this an acceptable way to go about this, or am I approaching this whole concept wrong?
Thanks in advance!
Don't Get Hung Up On Thinking You Will Just Write User Stories ... You Need Detailed Stuff To Develop From ...
As I stated Before ... I do consulting and have Never seen a 100% Waterfall or a 100% Agile environment ... most are a Hybrid of various stuff.
Agreeing with NitWitNick by-and-large, I want to add the below...
I always write user stories like "As a user with permission to xxxx...", and who has permission or what role has permission to xxxx... is a different reference document.
As you have already guessed, it is not always wise to describe everything in a user-story-like fashion. Every method has its use and purpose.
In a way it depends on the set-up of your project and your responsibilities, but what I like to do when describing the more detailed impact of permissions and roles is these 3 steps:
- Describe the user-story in a way: "As an administrator, I want ... " so the idea of who should be allowed to do what is commonly understood.
- Add a more detailed description for development in the form of: "IF the user does NOT have the permission xyz, THEN ..."
- Add a very seperate and standardized work-item for the user-administration or whoever does that in your organisation: "Add permission X to role Y. Add permission X to role Z. And in case the set-up allows it: Add role Y to user Patrick", etc.
Another suggestion: write your user story 'As a user I want etc'. Then in your acceptance criteria write a series of scenarios for each role. I use gherkin from the BDD camp to specify scenarios for acceptance criteria. Works well
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us