User stories are the "Director of Operations" view of the world. They describe step by step how the business works, and what the software needs to do to support it. They should be done after we have defined the user personas, to make sure we are starting from users and their goals.

An example

Let's say we are making a food delivery service.

A customer hears about the delivery service by seeing a flier on the counter when they are going to their favorite Mexican restaurant. They take the flier, and the next weekend it's raining, so they decide to try the take-out service.

They download the mobile app using the QR code on the flier and search for the restaurant's profile. They choose the food they want and make their order. We will assume cash on delivery at this point, though we could also use credit cards or some other mobile payment method.

The mobile app sends the order to the service website via the API, then the server notifies the restaurant that there is an order.

The cashier at the restaurant has the restaurant side of the mobile app in her pocket. It buzzes and she takes her phone out and confirms the order. Accepting the order schedules the driver to pick it up.

The cashier writes the order down on their standard paper order sheet and gives it to the kitchen. She adds the order number from the delivery system as well, connecting their order and the delivery service order. We could also integrate with their POS and kitchen management system, but that's out of scope right now.

The driver comes in with a list of orders on his phone. He checks off each one using the order number on the paper and leaves with the food in his messenger bag.

The driver's phone app gives him a suggested sequence of delivery locations. He goes to them one by one, giving them the food and taking the money. He checks off each delivery as he does it. The system knows where he is from the phone's GPS and can tell the customer when he is getting close to their house. The app can give directions to the driver using Google navigation.

What can go wrong?

There are various things that can go wrong at each step. These problems and how we deal with them are the most important thing to think about, they can make or break the service.

For example, the restaurant might be too busy to deliver when the customer wants. Or they might not acknowledge at all. Or they might make a mistake with the order. Or the driver might pick up the wrong bag.

We have some standard expected time frames, e.g. delivery within 45 minutes. So if the restaurant can meet that, then the cashier can simply acknowledge the order. If they are busy and can't do it in the standard time, then she might propose another time, e.g. one hour, or reject the order entirely. Then we would need to notify the customer to see if the time is acceptable or give them an opportunity to change to a different restaurant.

If we get the order wrong, the customer might accept it if we give it to them for free along with a coupon for another order. But if the delivery guy trips on the stairs and drops the food, then we have a bigger problem: a hungry customer and no food. We might need to expedite an order from the restaurant to take care of them. We might need a customer service phone number that they can call, as we can't expect delivery people to have good customer support skills. We also have a branding problem: the problems are generally going to be the restaurant's fault, but the service may get blamed for it.

We are relying on mobile phones a lot, but we need to make sure that we can survive if they fail. We would like to be able to start working with paper in the first implementation stage, then implement the mobile apps. We have a source of human error if we write on order forms, so a printer in the restaurant would be nice. But hand writing is still the backup. If the driver drops his phone and breaks it, he could maybe work from a print of the order stapled to the bag which includes the customer info.

We need to consider how having the cashier take a phone order will make customers standing in line feel about having to wait. This emotional aspect is an important part of user personas.

Next steps

The next step is to figure out what we need to get started running this business, and how software can help. If you can do it with Excel or paper in the beginning, then you can start running a "prototype" of the business and validating your assumptions. Other parts like a nice looking website might be necessary from a marketing perspective.

After user stories are done, we prioritize "paths" through the application, and write detailed technical use cases, estimate them and implement them.