Must an actor of a user story be a human being?

Question

User stories are traditionally written as expression "As a [User Type] I want [feature] so that [some benefit]". In the books and online resources [User Type] typically correspond to a role of a human being. However, when describing features of system internals, it is often easier to put some unattended service in place of a user, e.g. "As a ServiceX I want some data to be regularly refreshed to that I can do XYZ using most recent information".

Such form makes it straightforward to write easy-to-understand acceptance tests for related parts of the system. But is this conceptually right? Shouldn't user stories be based on features giving business value, and since systems and services are not interested in gaining business values, they should not be actors of user stories?

Lotty

Answer 1

Systems most certainly are interested in gaining business value. An actor could be an automated agent written by a third-party, and which embodies that third-party's intent. In fact, this is becoming a dominant form of interaction as web services become a more popular feature of major web sites, thus allowing complex inter-site interactions on behalf of users but involving only machines.

Calorimeter

Marcelo, but can't (and shouldn't) then the automated agent be replaced with the third party itself? E.g. if an automated agent runs currency rates update, shouldn't the user story's actor be a customer (or trader) whose business value is to get most recent rates? – Lotty

That depends on how you describe the user's engagement. Do you consider the user to be acting when their agent wakes up in the middle of the night and requests a status update on a pending online store purchase? Or what if a single act is performed on behalf of a set of users, or even an entire category of users. For instance, a social portal might hit a search engine to update the tag cloud for one or more special-interest groups. As a general principle, life is easier if you just model things how they really are. A piece of code is not a user, so don't pretend it is. – Calorimeter

"As a general principle, life is easier if you just model things how they really are." Yes, but is user story a model? Doesn't it just present motivation for a change or feature? What concerns me with system being an actor is that at some point (for a large project) business interests of stakeholders may change, but there is still a non-human system that wants something. – Lotty

You are over-thinking this whole thing. I am not using the term model in any formal sense. I simply mean that you should not get too wedded to cognitive abstractions when they don't fit the real world. Even humans can get stuck in a rut wanting something that is no longer necessary or important. This quality is not peculiar to machines. – Calorimeter

Perhaps I am overthinking, but I do not want to use user story for wrong purpose. Here's a quote from Goiko Adjic book "Bridging the communication gap": "The most important difference between user stories and more traditional techniques, such as use cases, is that user stories are there to facilitate the discussion and support planning rather than to be an authoritative description of system requirements." – Lotty

That's perfectly fine. No one is saying that you have to write a detailed functional spec for a non-human actor. The description can be just as informal as it is for a human actor, e.g., "A third party system may want to access our social network graph in order to discover relationships that aren't evident in its own graph. We want to facilitate this kind of interaction, but at the same time prevent wholesale slurping of our database." – Calorimeter

Answer 2

I don't see why an actor should have to be a human - your example is a perfectly good reason for it not to be.

The thing with methodology like this is not to get hung up about sticking to the minutiae of the defined practice. Even if the people who originally came up with the concept of "user stories" thought that they should only apply to humans, there's no law in place forcing you to stick rigidly to their concepts.

The whole point of user stories, agile, scrum, and all other methodologies is to assist with the development process, not to be the development process. A methodology is only valuable as long as it makes the process better, so that's how you should use it. You should feel free to adapt the methodology to suit your unique circumstances. Don't let the methodology become more important than the actual code development.

Pantagruel

Answer 3

Here's the secret. They're not user stories, but they are user scenarios.

The user is the thing doing the interacting - the machine, or a person.

The stakeholder is the person or corporation getting the benefit from the interaction (it's never a machine; not at this stage in AI development anyway). There are usually several stakeholders with competing needs for any given project. The primary stakeholder can be tracked down by working out who's paying for the project and why.

The user is rarely ever the primary stakeholder. Usually a stakeholder wants a user to do something so that they, the stakeholder, can get the benefit.

For instance, Twitter investors want users to enjoy Twitter so that they can keep all their options for making money in the future. Bosses want their secretaries to use word processors so that they can get letters typed faster and change their minds at the last minute. StackOverflow wants great posts to be upvoted so that they can get their advertising revenue.

Here's a blog post which I wrote on the subject, including a template you can use to separate the concerns of user and stakeholder. I leave it as an exercise for you to imagine who benefits when you, the user of the post, read it.

Revanche