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?
Finally, the “system” should never be used as the role in a user story. What the “system” needs to do does not speak to delivery of business value.
Actor: The 'owner' of the user story. This is often a user but it is recommended to be more specific here. By using specific actors (e.g. "Administrator", "Logged in Customer", "Unauthenticated visitor") it's easier to understand and sets the user story into context.
Which statement is true about the actor in a user story? The actor does not have to be a specified role in the solution.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With