User Stories and Job Stories: Are they Mutually Exclusive?
Last week, I delved into the User Personas — benefits and misuses. There are several vocal voices in the Product and Growth areas strongly in favor of and against using personas. For the rest of us, just like everything else, the truth is somewhere in the middle. Let's get into it a bit more.
A Prominent Issue with Personas
A significant drawback with personas: there are many details described who the persona is, except there is no clear indication of the situation and their motivation. Both of those are critical pieces of information to understand your customer truly.
User Stories
Now to the communication piece. How are you translating your understanding of the bigger picture into the granular bits so that you can help your product team and stakeholders deliver on the product design?
User Stories start with identifying a persona — "As a buyer, ..." If you need a primer on User Stories, there are many resources available: see here, here, or here.
Remember, a lot of things work in theory; the practice is of a different matter altogether. One common downside or misuse of User Stories is using "As a user, ..." When you refer to a generic user, STOP. Take a step back and assess who the user is — a seller, a buyer, a bidder, an admin, and so on. (Of course, there are some use cases where your persona is a user.)
Without identifying, and without all the work you're doing into formulating a persona, by casually referring to it, "as an X, ..." there are two immediate downsides:
You give an impression that you understand the persona, keeping aside the criticism of using the personas for a bit.
Calling most of everyone as users, you don't have enough understanding about your customer. Hence fail to convey the connection between your persona's circumstances and behavior.
Job Stories
So, the major arguments against the user stories are:
They don't provide context around the job executor's situation and motivation.
They're more focused on the solutioning or implementation than the understanding of the problem.
Enter Job Stories.
When I read this post by Paul Adams several years ago, the term Job Story was not coined, or at least not as well known. Then, When Coffee and Kale Competes provided food for thought with more details into Job Stories' concept. For a refresher on the Jobs To Be Done, see my write-up.
A Job Story has three parts to it, just like a User Story. However, A Job Story starts with under which situation a job executor is performing a job.
Examples
When I have new information, I want to ensure that it is linked to the already existing knowledge on a given topic so that I can find the relevant information easily.
When I'm on the go and the inspiration hits, I want to be able to capture my thoughts without losing them so that I can review them at a later time.
What you see from the above two examples is there is no mention of the technology or solution. You're primarily talking about a writer's needs with relevant contextual information. Even if the technology changes, which happens all the time, the Job Story is still intact.
So, Are User Stories and Job Stories Mutually Exclusive?
Not necessarily is my answer. Use Job Stories for the top-level description of product design: actors and interactions, and User Stories for the development. Link the user stories to the job stories by using whatever tracking solution you use.
At the risk of repeating myself — be ultra-cautious about your persona in the User Story. When you say, 'As an X, ...', that X better have a common understanding in your product team. If not, you're just going through the motions and checking the box.
As I was exploring this topic, I thought of asking Jim Kolbach that question. I recommend Kalbach's book on JTBD, a practical distillation.
https://twitter.com/JimKalbach/status/1371546062314475530
Related - Further Reading
Advances in Job Stories (Video)
The Dribbalization of Design — drives the concept of Job Stories via the design constructs