In our User Stories article, we discussed how creating good user stories can fuel agile success. While these non-technical explanations of features and functionality are written from the user’s or customer’s perspective, job stories allow you to focus less on the user performing some function, and more on the job to be done by that story. In this article, we show how you can use job stories instead of, and/or combining them with, user stories to define user tasks in a product's design, while simultaneously enhancing your agile projects.

What are job stories?

Believe it or not, job stories are not exactly a new concept. In fact, they were first developed at Intercom in 2001, and further refined over time using the Jobs-to-be-Done (JTBD) framework. According to Intercom, rather than focusing on what users want to accomplish, job stories frame every design problem as a job focusing on a trigger event or situation, the motivation and goal, and intended outcome rather than what users wanted to accomplish. In short, job stories are more concerned with motivation and outcomes rather than a user performing some function.

When should I use job stories?

In order to decide when to use job stories, it's important to understand the strengths of both user stories and job stories. I think Mike Cohn says it best: "User stories are most helpful when products have diverse users and fully understanding those users is imperative, which is why they are in the forefront. With user stories, who is performing the story is just as important as the action they are performing. On the other hand, job stories are better when a product has users whose needs are similar. In other words, who is performing the story is not necessarily important, which is why the situation is up front."

This is no more evident than when you find yourself writing a large group of user stories that each start with "As a user...". Suddenly, the user isn't necessarily that important anymore. Ultimately, they are used to justify a feature rather than establishing a better understanding of actual users and/or determining the best solution to meet their needs. And this is where writing them as job stories rather than user stories can be helpful. They provide additional context of when the story is being performed, and this just might be more vital than who performs it.

Like user stories, job stories should be written throughout your agile project. However, remember that each has its advantages and both techniques are compatible, so often using them together offers you the best chance of success. When determining when to write job stories versus user stories, think about the need for context and causality in the requirement. It can be quite frustrating for teams when they feel like they can’t ask "why," or find themselves locked in a particular sequence with no context. Job stories are all about context and causality as indicated below.

Using this format, the user situation triggers a motivation that leads to the expected outcome. This concept revolves around "when" and more importantly "why" a user wants to perform a certain task in contrast to what they want to perform and how they want to perform it. All the information in a job story is critical and extremely informative because the focus is on the relationship between cause and effect. When writing a job story, you should provide as much context as possible and emphasize motivation, rather than just focusing on implementation. If you understand the situation in which people encounter a problem to solve, understand the motivation for solving it, and understand what a good expected outcome looks like, the more likely you are to be building a valuable product for your customer.

Who should write job stories?

Like user stories, each team member is responsible for not only writing job stories, but also determining when a job story is a better alternative to a user story. Therefore, establishing a well-balanced cross-functional team consisting of diverse skill sets, experiences, and perspectives can contribute to a much better understanding of user and customer needs and motivations. This includes establishing clear communication and collaboration among team members, as well as confirming the right people are in the room to ensure everyone understands the desired outcomes and works together to achieve them. This also allows for more effective problem-solving, brainstorming, and decision-making, which not only ensures the context and causality that drives well-written and sensible job stories is ascertained and well understood, but also results in better crafted job stories that accurately reflect user and customer goals.

Can you provide some examples?

To determine when job stories may be better than user stories, it’s important to look at an example job story and its competing user story.

This example job story describes the behavior of a time-reporting application warning a user not to submit a timesheet multiple times.

When...	I want to...	So that...
...a timesheet is submitted	...see a warning message	...I can avoid resubmitting the timesheet.

The competing user story might have been:

As a...	I want to...	So that...
...user	...be shown a message telling me not to a timesheet twice	...I don’t place a duplicate timesheet

The job story is preferable in this example for two reasons. First, this story applies to everyone that submits a timesheet; basically, everyone in the company. Therefore, it's not important to know the person doing this is a user.

Second, the job story is better because it provides more context about when this is happening. It is happening "when a timesheet is submitted," as the outlined in the job story. When you look carefully at the user story, you'll notice that it never says when this message is displayed. The team could "successfully" implement the user story by adding an item on an FAQ page warning against submitting a duplicate timesheet. However, that is almost certainly not what the product owner wants.

What are the benefits of job stories?

In conclusion, good job stories can provide several benefits to your agile projects. Job stories are focused on creating a user experience (UX) design that keeps in mind the needs and concerns of real users. User stories tend to be more prescriptive, defining desired functionality based on assumptions about what a user needs. However, job stories will encourage your team to explore the underlying motivations behind a user's actions. This will allow you to gain a more comprehensive understanding of the problem and potential solutions. Job stories also address three key problems that are inherent with user stories: relevance, assumptions, and context. Job stories give relevance to "why" a user might use a certain feature; they mitigate assumptions that effectively close the door on potentially better and often more effective solutions; and they provide context around a user's underlying motivations for taking action.