index.md 19KB
title: Replacing The User Story With The Job Story
url: https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27
hash_url: 6512ff7a7e
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 people 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 referred 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:
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
Update: 2015–03–03: Based on even more usage & feedback, I use a slightly different explanation now. See these tweets of how I suggest framing it now. An update of this article will come in the future…
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.
[update June 4th 2014] After working with Job Stories for a while now, I’ve changed ‘Motivations’ to ‘Motivations and Forces’. Look to 5 Tips For Writing A Job Story which touches on this. Also learn more about the forces via this podcast and this short article.
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 to 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.
What About Multiple Roles & Events?
*Added July 28th 2014
As I get great feedback regarding Job Stories and as I continue to work with Job stories, I’ve found that sometimes it’s helpful to include Roles, or Characters, as part of the When_ clause.
Products With Multiple Roles
Roles / Characters are most helpful when the product has multiple roles, e.g. an IT product ( Admin, Manager, Contributor….) or in a marketplace product product ( Buyer, Seller ). The reason is just to clarify who we’re talking about.
Using eBay as an example:
When a Buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter bid notifications, so they can have enough time to evaluate and update their own bid.
Roles With Cause & Effect
Sometimes, there are situations when a Job Story effects multiple roles at once — setting up a cause and effect scenario.
Using eBay, again, as an example:
When a Seller isn’t happy with the bids they are getting and takes their product off the market, Buyers who have already submitted bids, want to be immediately notified that the product has been pulled, so that Buyers know they no longer need to keep tabs on the product and should look for a different, similar product instead.
Using Events Instead Of Roles
Sometimes, however, there might be a situation when an event effects all the roles or groups of roles: such as needing to get a password reminder. In this case there’s no reason to have a specific role, rather, try to keep it event based and general by using terms like customer or someone (but not user):
When a customer is on their mobile device and forgets their password, they want to get their password in a way that makes it easy to reclaim it via their mobile device, so they can continue to log in and access their news feed.
Why not user? User feels very lifeless and sterile, instead, customer reminds us that we have people who need to be served and respected.
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.