Utilization of User Stories for automated, scheduled, or reactive functionality

Question

I was wondering what the thinking is in regards to using User Stories to describe automated, scheduled, or reactive functionality. For example, what do you do when you have something like an order fulfillment process which involves pulling an order from a queue, preparing a "fill order form", sending the form to an order processing center, then waiting for some sort of confirmation from the processing center, such as "order fulfilled", or "order fulfillment error: reasons...", etc.. Keep in mind that the only user intervention during this entire process would be when the order was entered. One could always argue that the fulfillment process is something that can be implied from a order entry story, or that it is an implementation detail, but it seems to me that the fulfillment process is too large to simply take it as implied from an order entry user story or as an implementation detail. It feels like there should be a description of the fulfillment itself as a story as well.

Particularly, the aspects that interest me about writing a user story for automated, scheduled, or reactive functionality is from whose perspective should it be described? Given that we are using a story format like "As a [role], I want [functionality] so that [purpose]", what is the role in the "As a [role]" part of the story, and what is the purpose in the "so that [purpose]" part of the story? The functionality is usually clear enough but the role and the purpose seem a bit relative. For example, I could use the system as my point of reference and write something like "As the Order Fulfillment System/Agent, I want to be able to pull an order from the fulfillment queue, prepare a fill order form, and send it to the order processing center so that the order can be fulfilled". Or alternatively, I could look at things from the business's point of view and write something like "As an order taker, I want to be able to process the orders that are entered by customers so that I can fulfill my responsibility to my customers and give them what they want" (or something along those lines). However, I could also write this from the perspective of the customer and say something like "As a customer, I want to my order entry to be processed/fulfilled so that I can receive the things that I want".

I realize that there may not be one ultimate answer as to whose perspective is the valid one or more usefull one. I'm sure I will get a lot of "it depends" replies. Nonetheless, I would be very interested in hearing about what others have done in situations like these, or if anyone knows of any recommendations, guidance or practices specifically for these types of scenarios.

Answer 1

It might help to move away from the traditional user story template and towards the stakeholder-focused format of Feature Injection (BDD in the analysis space):

In order to <achieve a goal>
As <the stakeholder>
I want <someone to do something for me>.

You can work out who the stakeholder is by thinking about who would be willing to pay for the story to be delivered. For instance, CAPTCHA boxes - those annoying things users have to fill in - are done for a moderator's benefit, or to make the site more attractive to gain revenue, and not for the user's benefit at all! In fact, when you think of most sites, applications, etc., they're hardly ever done for a user. Most websites are about advertising revenue. Most enterprise applications involve one department entering data so that another department can use it, or so that money can be taken from customers.

When you do this, it becomes more obvious that there might be more than one user involved, and a user might be another system. In your case I'm guessing that some kind of sales head is the main stakeholder for this story.

In order to make sales
As the Sales Head
I want customers to be notified of any errors with their order.

In order to make sales
As the Sales Head
I want customers' orders to be fulfilled within 24 hours.

You can see from this that the goals become quite high-level, so if you have a piece of software which plays into those goals, you can break them down:

In order to fulfil customer's orders within 24 hours...

Now every story can be traced back to the project vision, and you can see all the systems in play. So your automated scenarios might read:

Given a valid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds successfully
Then the successful fulfillment should be logged
And the customer should be notified by email.

Given an invalid order in the queue
When the order fulfilment system runs
Then it should send a fill order form to the processing centre
When the processing centre responds with an error
Then the error should be logged
And the customer should be notified of the problem by email.

For instance.

By the way, if you're thinking of moving to this format now, be aware that the transparency it creates can cause absolute havoc with people who are, say, developing because they've got the budget, and not a proper project vision. I think this is a good thing. Others find the politics less comfortable! Good luck, whatever you decide.