Do you write your stories right?

By now, I hope most of the people who practice agile knows what a user story is.  I observed in lot of teams that either they don’t write user stories or don’t write them right. In this blog, I will try to explain the significance of writing a user story right way so that it adds value to the product.

Earlier I have two options either to choose restaurant business or to ask printing franchise cost to do printing business. I am going to take an example where we are going to build a website for a restaurant to improve the business.I often take this example since it is simple and every one loves food. Of all the possible features, most important features to start with are having a menu on the website, a way to order and a way to pay. Here are some requirements:

Feature #1: Need a menu on the website

Requirements:

1. A menu with all food items and their prices are present
2. Items are sortable
3. Items are selectable by category
4. Items have their ingredients specified
5. Items have their nutritional facts listed
6. And so on..

Feature #2: Place an order

Requirements:

1. A way to select items to order
2. Shopping cart
3. Provide address to deliver
4. And so on..

Feature #3: Payment Options

Requirements:

1. Credit/debit/cash card processing
2. Pre-paid store card
3. Check
4. Direct debit from the account (Net banking)
5. And so on..

When PO and team start brainstorming about the feature, various requirements popup randomly. But the question is what exactly business needs? How do we know where to stop the requirements and what requirements are even relevant to our situation.

Let us use the prescribed story template and see if that helps us scoping the story right. Here is the story template:

As a <Who> I want <What> so that <Why>

Who: Talks about who needs this story. You need to really understand your user for this feature. It’s not the restaurant which needs this feature, but it is the user who really uses the feature. Identifying the user could is two dimensional:

1. User type: Different types of users going to use the system, like employee, employer, admin etc. In our example “Customer” and “Admin” are two user types.
2. Persona: This is a representation of certain users with in the user types, like in our example, “First time customer”,  “Repeat Customer”,  “Health Conscious Customer” could be different personas of the customer. Identifying the right granularity for the customer is very important because you could focus on what that user (or persona) cares about. You could use highest granularity like “User” or “Any User” if the feature is applicable to all users equally.

In our example, the restaurant is just starting to go online and we want to get as many orders as possible. So, we care about any customer with “First time“ persona most and build the features those are relevant to them.

Why: Once you know the user, now you need to know why you want to do this story. Do you want to get most orders or you want to promote your restaurant as a healthier brand or something else? If this is a small restaurant and at this point you care most about getting lot of orders, that’s what should be your goal. Lot of times POs as well as engineers don’t know what exactly the purpose of the story. Knowing that would greatly help scoping the story as well as coming up with effective solution.

What: Now that we know who is your customer and what goal you want to achieve, we could scope what we want. We are still talking about the problem we are solving, but not the solution itself. For our example, we need a simple menu with items and prices listed that will cater to all general customers and gets the restaurant lot of orders.

So some of the stories for the menu feature are:

1. As any customer, I want a simple menu so that I can order what I want
2. As a first time customer, I want to be able to find items easily so that I can find items quickly. (We may choose not to implement this story since the menu is not that complicated and the customer will get used to it fairly easily)
3. As a Health conscious customer, I want to see nutritional facts of each food item so that I can choose healthy food. (We may do this story when we want to address that special customer base)
4. As a repeat customer, I want to have my favorite items listed so that I can choose from what I like most (We may want to build this story as we are getting repeat customers)

We could do the same steps for features for “How to Order” and “Payment Options” which I am not going to do here.

How to choose the right solution:

Let us take the story #1 and see how we decide on the implementation. This story is addressing major customer base that just care about a simple menu.  Once engineers understand the story and it’s vision, they could come up with appropriate solutions. Some of the cost effective solutions are:

1. A static picture of the menu with a number to call.
2. An html menu, driven by a data store. This could be sortable. However, this needs an “Admin” user to maintain the data store. This solution helps in adding any future enhancements like adding a feature to click on the item that gives information like ingredients of the item etc.

Now, how do we choose between above solutions? Option #1 is very cheap and achieves the goal. Option #2 is more expensive but inline with future expansion. The answer is, it depends on what situation you are in.

Let’s say option#1 takes 1 week to complete and option#2 takes 1 month. If you go with option #1, you need to throw away the feature when you want to enhance you system. If you go with option #2 you won’t be releasing the feature for 1 month and you lose orders during that period. So, you need to do the cost-benefit analysis to see which approach to take. Some possibilities are:

1. If we are just starting out, you may want to go with options #1.
2. If we are somewhat an established business and want to go with long-term vision, we should go with option#2.
3. We could build both stories at the same time and release them, as they are ready. This is viable only if the revenues you are going to generate in that 1 month are more than the cost of building option#1.

Product owners and engineers need to go through this kind of thought process for creating and implementing all user stories.  In our example, we could go with:

A static menu card image with a phone number to order and pay cash on delivery as a payment option

Or

A sophisticated menu system with a shopping car to check out and credit card processing as a payment option

Or

Some solution that is in between

To conclude, you need to understand WHO, WHAT & WHY of your user story at the right granularity to come up with stories that add value to the business.