Why I don’t write User Stories… and write Job Stories instead

“When I <situation>, I want to <something> so I can <whatever>.”

The job story template says: “when I <situation>, I want to <something> so I can <whatever>.” So job stories focus on thinking about the context in which the user wants something to happen. In comparison, a user story (“As a I want to, “) is very focused on who the user is and what they want.

Suppose you’ve got a problem that will be addressed for multiple user personas. In that case, user stories start to get a bit confusing. You begin to get some overlap, and you often end up with gaps between those stories.

In my opinion, the context of “when” is vital while developing any feature or functionality and user stories leave it out. A job story brings that to the forefront; the person’s context can and should shape the solution.

Let’s go by an example. Let’s say that you’re in college or in high school and you’re running between classes. And you’re hungry. You want to get something to eat.

In a user story, the user story would be, “as a student, I want to eat because I’m hungry.” A perfectly good user story, but there’s some critical context needed to determine the best possible solution to this problem. Without it, let’s say the answer might be a steak.

Perfectly valid, but then you need to dig into the details in the specification of your user story (where the necessary context of the user is hopefully included).

In contrast, with a job story, the context is placed front and center, so you can leave the detail for the detail. For example, for a job story, “when I’m rushing between classes and hungry, I want to eat something, so I can pay attention in class.”

And so thinking about that, versus “as a student, I want to eat something,” you’re solving a very different problem.

A perfectly valid answer to that user story is a steak. But in the job story, “When I’m running between classes,” steak probably isn’t the best solution to that particular problem.

As product managers, we’re very focused on finding the problem worth solving. We think a lot about the problem, and we should have gathered a lot of context about it before trying to solve it. The job story structure encourages us to capture that.

At the granularity of a specific story, that context is essential to developing a good solution. Back to our example, “when running between classes and I’m hungry, I want to eat something, so I can pay attention in class.” A sound solution to that is perhaps a slice of pizza, a snack bar, or even an energy drink.

With a job story, you can take the user’s context and identify and think through the many possible solutions.

For me, job stories are a better tool. A job story allows you to really tie in all the most important details right there in the story itself, rather than burying them in the details.

If you enjoyed this content, it’s an edited transcript of a sub-module in my crash course: Product Management — Beyond The Basics (available on Udemy).

Originally published on Bryce York — The Product & Conversion Guy