User stories have become the standard approach for creating product backlog items.
But that doesn't mean user stories are right for every product or feature that an Agile team works on.
As useful as user story can be, they've never been right to every team.
An exciting alternative for some teams is the job story.
Job stories originated at Intercom and were best explained by Alan Clement.
Job stories get their name from and are based on the jobs-to-be-done research of former Harvard professor Clayton Christensen and his colleagues.
That research led to insights that organizations often focus too much on categorizing users based demographic and psychographic data.
Demographics are objective data such as age, gender, and income.
Psychographics, are subjective and include things like goals, values, attitudes.
These characterizations lead to creating personas or user roles who represent different buyers or users of a product.
The jobs to be done theory says that organizations should focus more on what customers or customers hope to accomplish.
That is, we should focus more on the job to be done at the moment rather than on demographic or psychographic information about the user doing it.
Job stories de-emphasize who it is that's performing the action, which would traditionally be captured in a user story.
This leads to a different template commonly in use for job stories.
That template is when some situation, I want to do something so I can achieve this outcome.
As with the Common User Story template, there are three parts to the Job Story Template.
The first is a trigger or situation.
And that provides context on when the story is being performed or what action initiates the Story.
Examples could be when an order is submitted.
when searching by postal code, when no matches are found, or when looking at recent orders.
The second element of the Job Story template follows the I want to and provides the motivation for the story.
Think of a motivation as a user's stated or first order goal.
the third part of job story is the expected outcome.
think of this as the user ultimate goal as an example, I work with the video editor, Steve, to create these videos.
In case you're wondering, that's me.
When I record a new video, I want Steve to be notified automatically so that I can add the video to YouTube without delay.
My ultimate goal is to post new videos to Youtube soon after I recorded them.
I don't really care about Steve getting a notification, but that is the middle part of the story template, the motivation,
because it's how I think I could be able to make a video more quickly.
But if I give this story to a team and they have a better way of achieving the expected outcome, that's great.
To see the times when job stories may be better than user stories, let's look at some sample job stores and their corresponding user stores.
Let's start with this job story.
When an order is submitted, I want to see a warning message so I can avoid resubmitting the order.
This story describes the behavior seen on most e-commerce sites warning a user not to submit an order multiple times.
The user story equivalent of this might have been, as a customer, I want to be shown a message telling me not submit a order twice so that I don't place
a duplicate order.
The job story is superior in this case for two reasons.
First, this story applies to everyone making a purchase on the site.
So it's not important to know this person is a customer.
Second, the job store is better because it provides more context about when this is happening.
It is happened when an order is submitted, as the jobs story tells us.
Look carefully at the user story and you'll notice that it never tells when the message is displayed.
The team could successfully implement the user story by adding an item on an FAQ page warning users against double submitting orders.
But that is almost certainly not what the product owner wants.
Let's look next at entering the shipping destination when placing an order online.
The job story version is, when entering a shipping designation, I want the address filled in as I type, so I don't need to type all of it.
A user story version of this would be, as a buyer, I want the address filled in as I type, so I don't need to type all of it.
These two stories highlight the difference between user and job stories that exist in the first part of the template.
The when and as-a clauses differ, but in this example, the remainder of each story is identical in both user- and jobs-story format.
As in the first example, the job story is better here because of the additional context it provides around when the story has been performed.
Who is performing the action?
Entering an address in this case is not important, which is why the user story got written with the generic as a user.
In deciding when to use job stories, I think it's important to acknowledge that both user and job stores have unique strengths.
I still find user stories most helpful for products that have users who vary significantly and when deeply understanding those users is important.
This is why user story start with as a type of user.
We start user stores that way because doing so puts the user right up front.
In contrast with a job story, it is not important who is doing the story.
This makes job stories the better option when your product has users, but their needs are not very distinct.
If you've ever written a lengthy set of user stories and started each one with, as a user, you have encountered this situation.
When a large set user of stories all begin with as user recognize that you got a set stories for whom the user is very important.
Writing those as job stories rather than user stories would be helpful.
Doing so would allow this story to include the additional context of when the story is being performed.
In some cases, like these, knowing when a story might happen is more important than knowing who will perform it.
You do not always need to choose between a job and a user story.
It's possible to merge them and get the benefits of each in a single story To see how, let's revisit our user-story warning people not to submit duplicate orders.
That was, as a customer, I want to be shown a message telling me not submit an order twice so that I don't place a duplicate order.
As a user story, it is missing the context provided by the job story's win.
But we can add that, transforming this story to, as a customer, when I place an order, I want to be shown a message telling me not to submit an ordered
twice so that I don't place a duplicate order.
So when should you prefer user job stories over the other?
First, know that each is great and has its own advantages.
On any given product, I write some of each.
The two techniques are quite compatible, and there's no reason to view them as mutually exclusive.
If your product has users and those users' needs differ in important ways, I suggest user stories.
The additional emphasis a user story puts on who is performing the action can lead to insights about user behavior.
If, however, your products' users do not differ significantly, job stories are likely the better approach.
A good starting point is to mix user and job stories in the same product backlog.
Start by writing job story any time you find yourself tempted to write a batch of stories all beginning with as a user.
Job stories represent an important advance in building great products.
The jobs-to-be-done framework rightly shifts thinking about demographic and psychographic commonalities among users to instead thinking of their common needs,
the jobs to be done.
What do you think of job stories?
Would they be helpful on your product backlog?
Have you worked with job stores already?
If so, were they helpful?
Please share your thoughts in the comments.
If this video has been useful, click the like button.
And if you're new to the channel, please subscribe so you don't miss out on future tips.
Thank you for watching and I'll see you next time.