I work as a UX-designer and have some experience with user stories from agile development projects where they were used to document functional requirements on the form:
As a [type of user] I want to [goal] so that [reason]
After a discussion with some colleagues we identified three different interpretations of what a [type of user] is supposed to be.
- For me as a UX-designer the [type of user] would represent a persona, an archetypical end user or customer built from user research on real people.
- One of the developers said the [type of user] was a role in the software, for example a medic or a sniper in a war game.
- A project leader said the [type of user] represented team roles in the development project, for example a tester or a developer.
Who is right? If all of us are right, wouldn't this be a common source of confusion?
1 and 2 are very common in use. I've worked with many teams who created a number of persona's for their product, say Jane the elderly lady, Daphne the hipster who does everything with her smartphone and John the executive who lets everything be arranged by his personal assistant.
These personas have very different requirements of a piece of software even though they may be performing the same function in the system or are acting from the perspective of the same role.
The value statement for one may even conflict with the value statement for another. Where Jane might want a large font and only the information relevant t her current action, John ('s assistant) may want to have a broader view and doesn't mind visualizations and small fonts if it means she can cram more information on the same screen.
So see the personas as a way to further scope down specific roles and make your user stories more "human" by staying away from tightly scoped roles. Remember, the user story is meant to really tell the story of a user and what the functionality will help him/her accomplish and what that would bring to these people. The roles "administrator", "customer", "gold customer" tend to be empty of emotion and often don't lead to the right discussions.
I remember some team discussions where people remarked mid-discussion: "While John would love that, we'd have lost Jane 3 steps ago". Which lead to a change in the proposed functionality.
As for option 3, I see quite a few teams do that, and for certain roles it may make sense... As a operations engineer I need thorough logging in order to analyze production incidents quickly. could be an example. But teams taking it to As a requirements analyst I need the requirements for story 27 is taking it too far. Often these items fall in the non-functional requirement bucket and do not provide true end-user functionality. For these types of Product Backlog Items you may need to check whether a User Story is the best format to describe them.