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?

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.

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.

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.