What is a 'type of user' in a User story?

Question

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.

1. 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.
2. 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.
3. 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?

Answer 1

User stories best used to describe the requirements from the product backlogs so that how the end user or stakeholder will see and use the product from his point of view. And PO should be the best person who can comment about the correctness of the user story. If PO is taking input from team for the development of user stories, the one should visualize more on the usage of the product rather than simply classifying the type of user. Though the type of user are important, but the emphasis needs to be given to usage such as, 1. the doctor accessing the medical website to know the content of the drug and its manufacturer so what kind of access needs to be given to him on the other hand 2. if the druggist is looking for the particular drug, available quantity, shipment time then according access and workflow needs to be provided.

From the above given usages, I find the 1st one as appropriate i.e. persona and its the usage of the system from his point of view. For each usage of the system, one can create user stories and accordingly the workflow can be developed.

Answer 2

TL;DR All are useful, none are wrong and none are the only way. Read more on a blog post I wrote to follow up this answer.

The 3 nuances you describe are each valid and provide useful information. Consider trying each to see which works best for you. My advice would be to avoid restricting what 'user' can mean as it may cut you off from useful insight and deeper meaning into what you're building

The goal of a user story (originally, Kent Beck wanted them to be just called 'stories') is not to write better user stories; it is to go beyond requirement and into true understanding. For this, you need to who who the software is for, what problem it is solving for them and why that problem is valuable to be solved.

Consider this as an experiment to know if you have the right type of user. Answer the question, "Do I know how this thing I'm building will change the world of those who will use it?" If not, you may not understand yet who it is for.

Answer 3

To answer as short as possible: the person is a "stake holder".

Now what is that stake holder? It is the person having the (biggest) benefit of the story tasks to be performed.

• Most general it's the app user. It can use a new feature.
• It could be a developer, e.g. the story could intend to make an app more resilient
• It could be your manager, maybe there is a risk to be closed

And many many more. As long as it's getting benefit of this story to be finished.

(side note: I never liked this way of story writing. too many boilerplate, but also our agile coach urges us to write stories in this format)

Answer 4

The first and second are right but they are not different, rather are complementary.

Type of user can be:

• Joe a person.
• A banker, some rol.
• Joe the banker, a person that have a rol.

In resume you can use any context for a type of user, so you can use one of them or a mix.

Hope my english can be undertand =).

Answer 5

User stories are written in the language and from the viewpoint of end users of the product.

So the user's are exactly that: they are users of the system.

Examples include:

• A doctor using some medical software
• A shopper using an online shop
• A product manager using a product report

Answer 6

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.