Swap user stories for job stories when your persona is boringly unchanging
TLDR; A user story goes like this:
“As a persona, I want an action, so that I get an outcome.”
However, the persona is often unchanging and at the same time, simply an undeveloped label. User stories are also often manipulated to simply accommodate what you want to build anyway. Job stories swap out the persona and the action, like this:
“When I’m in a situation, I want to motivation (and force), so that I can expected outcome.”
A situation is more specific than any persona, while motivation gets at something more fundamental than simply wanting an action. Force further contextualizes the motivation, for example, if you’re in a rush, why so? (Maybe because you’re hungry.) By including situation and motivation, job stories encourage first principles thinking, increasing the chance that a solution addresses underlying needs.
You might justifiably keep user stories when you have richly varied and well understood personas, otherwise you can go with job stories.
Background
Anthony Ulwick developed Outcome Driven Innovation over a number of years prior to 1999. Ulwick introduced the idea to Clayton Christensen, who then talked about jobs to be done in his book Innovator’s Solution. Here is Christensen talking about the idea.
In 2013 Alan Klement introduced the idea of the job story, developed at Intercom in response to their dissatisfaction with user stories.
David Wu later suggested that force needed to be added to motivation, Klement writing:
Another idea from David Wu is to include forces with motivations. In the job story format of Situation — Motivations — Expected Outcomes, the Motivation stage can be augmented by adding pull and push forces. Adding forces to a motivation is much like adding context to a situation.
Rick Cohn added perspective to the discussion about user stories vs job stories, pointing out that one doesn’t always have to be favored over the other:
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 product’s users do not differ in significant ways, job stories are likely the better approach.
Other writers on job stories
Designing for motivations and outcomes is far better than designing for attributes. This is the key difference between Personas and Job stories. Personas look at roles and attributes, Job Stories looks at situations and motivations. Personas explain who people are and what people do. But they never fully explain why people do something. Why people do things is far more important.
By adopting the job story framework, organizations can unlock several benefits:
- Deep Understanding of User Needs: Job stories encourage teams to dig deeper and gain a comprehensive understanding of the user’s motivations and desired outcomes. This understanding allows for the development of more relevant and impactful solutions.
- Customer-Centric Approach: Job stories shift the focus from features to outcomes, enabling teams to prioritize customer value. This customer-centric approach fosters innovation and ensures that the product meets the customer’s real needs.
- Opportunity for Innovation: Job stories provide a fertile ground for identifying new opportunities and innovative solutions. By understanding the broader context of the user’s job, teams can uncover unmet needs and develop unique value propositions.
- Cross-Functional Collaboration: Job stories promote collaboration across disciplines. They allow designers, developers, and product managers to align their efforts and work towards a shared understanding of the user’s job and desired outcomes.
There is a very slight but meaningful difference between the two. By removing “As a __ ” from the user story, we remove any sort of biases that the team might have for that persona. Personas create assumptions about the users that might not be validated.
In my experience, user stories have a tendency to be easily manipulated to proposing a solution rather than explaining an expected outcome for that particular user. In particular, I’ve found people leave off the “so that __” in a user story with the feeling that it is optional. This leaves off the benefit that the user would get from adding new functionality.
In a jobs story we replace “As a __ ” with “When __ ”. This gives the team more context for the user’s situation and allows us to share his or her viewpoint. Next, the “I want to __” is transformed into situational motivation in the job story, as opposed to a prescriptive solution for a persona in the user story.
Because the differences in wording are negligible, it was an easy transition to shift from writing user stories to jobs stories. During this process, I noticed that the entire team had more empathy for the user. By placing the user’s situation upfront, our team had a better understanding how it felt to be in the user’s shoes, as opposed to thinking about a particular persona. This allowed for more discussion of the expected outcome and how to best go about achieving said outcome for the user.
When we first started using jobs stories, I was a skeptical that a small change in language would make such a difference in the way we build applications. Jobs stories have far surpassed my expectations and will be the way I write feature stories for all project moving forward.
When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so I can go out to dinner with my friends.
When someone wishes to withdraw money from his/her account, the customer wants to know if funds are available, the teller wants to know if the person banks with us, so that the person requesting can received the desired cash amount.
“People don’t want a ¼ inch drill. They want a ¼ inch hole.”
“When my credit card expires, I want to be able to change my credit card so that I can continue purchasing without any problems.”
“When my credit card expires, I want to be notified so that I can update my information without any disruptions to my service.”
