Replacing The User Story With The Job Story

http://alanklement.blogspot.kr/2013/09/replacing-user-story-with-job-story.html

Replacing The User Story With The Job Story

*A newer & better version of this article can be found on medium.

I've written about the problem with user stories before. At the time, I found it better to just have the team talk over proposed changes to the product. This worked great when the team had gelled and the product is very mature; however, now I'm working with a new team and building a product from scratch. In this case, because our canvas is blank, we are having trouble getting on the same page when it comes to customer motivations, events and expectations. But today, things have turned around. I've come across a great way to use the jobs to be done philosophy to help define features.

I call them Job Stories.

Where It Comes From

The idea comes from the really smart guys at intercom. Here is what is they say:

We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: 

When _____ , I want to _____ , so I can _____ . 

For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them.

It's not refereed to as a Job Story in the article, but I'll call it that so I can easily reference it in the future.

The article doesn't spend a whole lot of time with the concept, so I'll talk about why I like it and why it's better than User Stories.

The Problem (Again) With User Stories

Summed up, the problem with user stories is that it's too many assumptions and doesn't acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there's no room to ask 'why' - you're essentially locked into a particular sequence with no context.

Here's how I see the format:

Assumptions and disconnect between there persona and action

The first problem is that we start with a Persona, which is a very bad idea, and then plop in an action which we think should be taken in order to achieve the expected outcome. As I've marked in the above image, there's really a disconnect between the action and persona.

Here, let's look at some existing User Stories:

In the above chart, when someone reads moderator or estimator is that really adding anything? If anything it's adding ambiguity to the flow. You and I are going to attach our own interpretation of what a moderator is or why they are in these particular contexts.

Here, try this. Chop off the whole As a / an segment and see if you're really losing anything. Compare these two:

As a moderator I want to create a new game by entering a name and an optional description

VS.

I want to create a new game by entering a name and an optional description

Did the sky fall?

The Job Story : All About Context and Causality

Check out the image above. Now we're cookin'!

All of the information above is critical and very informative because we're focusing on causality. Each job story should provide as much context as possible and focus on motivation....instead of just implementation.

Let's rewrite some examples from the user story chart above as a Job Story and add motivation and context to each one.

User story: 

As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.

Job Story:

When I'm ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.

---

User story: 

As an estimator, I want see the item we're estimating, so that I know what I'm giving an estimate for.

Job Story:

When I find an item I want to set an estimate for, I want to be able to see it, so that I can confirm that the item I'm estimating is actually the correct one.

--

User story: 

As a moderator, I want to select an item to be estimated or re-estimated, the team sees the item and can estimate it.

Job Story:

When an item does not have an estimate or has an estimate I'm not happy with, I want to be able to restart the estimation process and notify everyone, so that the team knows a particular item needs to be estimated upon.

Define Motivations, Don't Define Implementation

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how, they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.

*update: A follow up article: '5 Tips For Writing A Job Story' is now online.