Writing User Stories When There’s No User

One of the first things most of us learn when we make the transition to Agile business analysis is how to write user stories.

If you’ve started your Agile journey, you’re probably familiar with the format: “As a , I want to so that I can ”

However, what happens if you don’t have a user, but instead are dealing with a system? When I started working in Agile, I didn’t have users to write user stories for, I had APIs and file transfers. The users in my case were the systems that would consume the output from other processes and create output used by other processes. 

I had to come up with a different way of thinking about user stories. The user isn’t directly involved in the process, or was involved so early in the process, that they don’t have much input or effect on it. I found it was hard to identify roles or user profiles to include in the usual format. This article is about how I learned to work differently to address that question.

When there isn’t a user, the purpose or value of the story has to become the focus. The system should always act the same given the same inputs, so there isn’t the kind of variation you would see with a human user. What becomes more important is the reason the story exists at all: the reason for the system to behave a certain way. Granted, the value of the story is important whether or not a human user is present, but it becomes more important in this case.

In my world, most of the requirements come from changes in state law or legislation, so the reason for a story is quite often to comply with regulations, or to provide required information to the state. In other cases, the department that handles reporting and inquiries from the state needs information to be processed in a certain way, but still doesn’t have direct interaction with the systems that do the processing.

Advertisement

In order to deal with this problem, I use a couple of different formats to write my user stories when a user is not the subject of the story: “In order to/for , the system .” I try to include the business unit or entity that has the objective in the first clause, as it makes the value of the story clearer.

So for example, I might write “In order for the state to process vehicle records properly and to provide efficient transmission, the system sends a valid driver’s license number with each record.” In this instance, the value of the story is that the state is able to process vehicle records properly. If I wanted to, I could go into more detail about that, but since all of the people in my team know why this is valuable, it’s not required. 

I can, and often do, provide details about the objective not being achieved as part of the story discussion or as part of the acceptance criteria. This story would probably be part of a larger epic describing what a valid record means for that state, listing all of the fields that need to be validated before a record can be sent. I might include the detail about the consequences of invalid records being sent at that level, since it applies to all of the data in the record. This story is one part of that epic, but keeps the focus on just one data element. I like doing things like this as epics because it’s easier in a case like that to combine stories or separate them to to organize the work.

Another way to write these, if you prefer, is to say “Because , the system . Again, I try to include who made the requirement necessary in the initial clause to make things very clear as to why the story is valuable.

After I discussed this with some of my fellow BA types, one said, why not make the system the user so you can use the usual format? For example “As a , I need to , so I can . This is a perfectly acceptable way of doing things. I do think it takes the emphasis away from the value of the story, which is why I prefer the first two formats, myself.

Once we’ve written the user story, most of us know that the next step is to write acceptance criteria and provide other information that the developers might need to implement the story. In this case, I would need to provide rules for identifying a valid driver’s license number for the state in question. I would also need to provide a set of acceptance criteria to give the developer a way of knowing when the story was complete. 

Most of the time this is in the form of use cases or a list of business rules that describe the incoming data, and what gets done about it in terms of error messages, logging, or other responses to the data. This might actually create an ancillary user story involving a human user, for example “As a state reporting specialist, I need to receive an email when a record is rejected by the state.”

Writing user stories is an essential skill for Agile business analysts. Focusing on value is one way to address “userless” user stories. While value is always important, it becomes especially critical when user behavior is predictable and definable.