Refining a User Story

I have talked about the purpose of a user story and the idea of keeping stories straight to the point. I’ve recently run into a good example of how a user story could be improved, and I’ll share it here with you. The original story looked somewhat like this:

In order to quickly navigate through Sales Orders
As a salesperson working at my desk
I want to see a list of all existing Sales Orders
So that I can navigate to Sales Order that I need to take an action on quickly 

I get that the person wants to navigate through sales orders “quickly”. But why is that important? To get back to playing Candy Crush or scrolling through social networks?

In a conversation with the domain expert, I’ve learned that such a person takes calls from customers all day, so that’s why it’s important that the sales order lookup happens quickly; the business wants to take care of all of their customers, not letting them wait on the line for too long, and taking the necessary actions quickly.

With that clarification, let’s think of the following bit: “I want to see a list of all existing sales orders”. Does that mean “all existing sales orders on the entire database“? That could be a very long list!

After further clarification, the user really needs to see only a list of service orders for the customer who’s currently on the phone.

That information reveals some interesting bits:

  1. The system only needs to present a limited list of results to the user (which certainly helps with the “make it quick” need);
  2. We’ve learned a little more about the context to which this user story brings value: not only is the user “working at his or her desk“, but there’s a specific customer on the phone! That little gem tells us the one filter we can immediately apply to the search.

I’d then ask the following question next:

Does the user want to see all service orders for the given customer, or only the ones where the status is “open”, or “pending”, or “my goodness, this case really needs attention!”?

Maybe the answer is “well, most of the time the user needs to see the open orders, but having to see the pending ones also happen quite often. They almost never need to see the closed orders, though.” 

That last bit of information can help tremendously the effort of providing a good User Experience; the system can take that information into account and maybe preload all of the open orders for the customer, as soon as the user indicates which customer is on the phone (the system could even detect who the customer is by looking up the phone number in the database, if such info and integration are available).

With that understanding, maybe the user story could be rewritten like so:

In order to better assist a customer and quickly move on to the next customer
As a Salesperson taking a call working at my desk
I want to quickly see the customer’s Sales Orders, filtered to the “open” orders, and have easy access to the “pending” ones

Notice that the original story mentioned “So that I can navigate to a service order that I need to take an action on quickly“.  

What are the actions that this user may take given this context? The conversation about would certainly produce an entirely separate user story. Depending on the number and nature of the actions, it’d even be multiple user stories, one for each action.

  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: