When crafting user stories, is it OK to name some non-human part of the system as your user? You may be creating requirements masquerading as user stories.
A common user story format
You are probably already familiar with this standard user story format:
As a <type of user>
I want <some capability>
So that <some benefit>
During the course of working with various development teams, I’ve run across stories like this more often than I would have imagined:
As the database, I want to have a Customer table, so that there is a place to store customer information.
As the system, I want to have an account object, so that account information can be seen.
The examples above certainly follow the standard format for user stories, but that doesn’t necessarily mean we’re getting all that we can from them. Either could be re-written as a simple requirement:
The database shall store customer information in a Customer table.
The system shall store account information in an Account object.
What we have here is a case of requirements masquerading as user stories. Note that both the faux and true user stories specify what is to be built. The difference is that the faux user stories leave out important information that true user stories convey, namely who the user is and why the story is being implemented.
These are important pieces of information, as they aid in determining that we’re building the right thing. In short, if a developer knows why something is to be built, and for whom, then he or she can make more intelligent decisions about precisely what is needed. And this can result in building something that is more useful and less expensive.
So if a simple requirement expresses the same thing as a so-called user story, why go to the trouble of bending the requirement into the shape of a story? Why do we see as many examples of faux user stories as we do?
My guess at the most common reason is that developers have been taught, or have led themselves to believe, that all features of a product must be expressed as user stories.
Another reason may stem from claims I’ve heard fairly often that are typically expressed as something like, “The work I do doesn’t have a user.”
Scrum says nothing about user stories
Scrum is the most commonly used framework for Agile development. And contrary to what many have been taught, Scrum says nothing about work items being expressed as user stories, but instead refers to them generically as Product Backlog items. Additionally, Scrum does not even require that all backlog items be of the same type or format, so a mix can be perfectly acceptable.
Now, to be clear, I’ve got nothing against user stories. I think they’re a very effective way to express the capabilities a system provides, and I use them almost exclusively when doing development work. My objection is to time-wasting efforts to express all work to be done in user story format.
Depending on your development environment and culture, you may be most comfortable populating your Product Backlog with a mix of true user stories and technical tasks.
My personal preference is to put only true user stories in the backlog, and to let any user story spark the creation of any necessary technical, under-the-hood stuff. But to do that, I have to engage in a mental exercise that I call:
Dude, where’s my user?
First, when I say “user” I mean some human-type person—not a data structure, a software component or other aspect of the system being built or a system that uses it.
User doesn’t necessarily mean a person interacting with some user interface. It means the person using your product, whatever it is that you produce. So if, for example, you produce web front-ends, your user probably is interacting with a user interface, and you should have little trouble identifying that user. If, however, you produce an API for a web service, your user is likely to be another developer, and you can write your user stories accordingly.
If you can’t easily identify one, you need to ask yourself, “Dude, where’s my user?” Because there probably is one out there somewhere. You may need to follow the path from your product through one or more other connected systems, until you find that person.
And If you can’t ultimately identify a user who benefits from what you are about to build, perhaps you should reconsider whether you’re building the right thing. Products are ultimately created for the benefit of human beings, so if you can’t find those people, either keep looking or stop building.