Most Agile development teams follow a familiar process when it comes to developing features: The product manager writes user stories and developers pull them from a backlog into a given sprint. After discussing technical requirements, the user stories are converted into tangible features during the sprint before being deployed to production.
Let’s take a look at what’s wrong with user stories, how job stories can help, and where they fit within the larger Jobs to Be Done theory.Job stories have become a popular alternative to user stories that focus on customer motivations while decoupling solutions. Click To Tweet
What’s Wrong with User Stories?
User stories in product management are the most popular way to describe new features to designers and developers with more context than a specification. Using personas that represent actual users, user stories seek to explain what actions users want to take to affect certain outcomes. They can even be included in testing suites using techniques like behavior-driven development (BDD).
A typical user story is structured like this:
“As a [persona], I want to [action] so that [outcome].”
There are three key problems with user stories:
- Relevance: User stories contain personas that contain a lot of irrelevant information. For example, a person’s age, sex, race, daily habits and other characteristics or demographics don’t necessarily explain why they might use a certain feature.
- Assumptions: User stories use actions to provide a solution to a given situation. Of course, they assume that it’s the best action to take to solve a problem. These assumptions effectively close the door on potentially better solutions.
- Context: User stories ignore a lot of context by leaving out a user’s underlying motivations for taking an action. If there’s a lot of frustration, maybe the feature is an unnecessary workaround for a deeper problem elsewhere.
At the core, the problem is that user stories are often used as a definition for a feature rather than as background for a solution. They are often seen as a justification for a feature rather than a way to better understand actual customers. Unfortunately, a failure to understand customers translates to wasted time and potentially subpar features.
What Are Job Stories?
Job stories were originally proposed by Intercom back in 2013. Since then, the idea has fermented and evolved into a new way of thinking about feature development. Rather than connecting a problem with a solution via a user story, job stories are designed to be independent of solutions and facilitate a better understanding of what customers want to do.
A typical job story is structured like this:
“When [trying to do something], I want to [motivation] so that [outcome].”
There are several steps to using job stories:
- Interview: Interview real customers to discover the true context behind a job to be done and all of the other relevant information. Rather than relying on made up personas, focus on sourcing real context from real users. The added context is helpful for better understanding the true motivations behind customer actions.
- Design: Design job stories that are independent of solutions. Rather than defining the implementation, focus on the user’s motivations and forces that may influence their decisions (e.g., anxieties or other factors that influence the problem). There could be five or ten different forces for each job story.
- Solve: Feature development should focus on identifying potential solutions for each job to be done. In some cases, there may be multiple solutions (e.g., features) capable of solving a given job or a single solution for multiple jobs. The idea is to find the best solution for what the customer really wants to accomplish.
The difference between job and user stories is trivial in terms of sentence structure, but the shift in thinking can be profound across an entire team. Rather than thinking about a hypothetical persona, team members can place themselves in the customer’s shoes and engage in better discussions about how to best achieve their desired outcomes.
Jobs to Be Done Theory
Job stories are typically used within a wider framework of thinking known as the Jobs to Be Done (JTBD) theory. According to JTBD, a Job to Be Done is the process that a consumer goes through whenever he or she aims to change his or her existing life situation into a preferred one but cannot because there are constraints stopping him or her.
When developing software, the JTBD theory suggests that organizations focus on solving customer problems rather than developing features. The simple shift in mindset can help organizations remain focused on a singular goal while better conveying to customers why they should consider using the product to improve lives.
For example, suppose that you’re developing an email application. Rather than assuming that users want labels to organize their emails, you might step back and realize that people really just want to sort their most important emails. Labels require a lot of effort to assign to reach email, but automatic categorizations with machine learning might be a better solution.
The Jobs to Be Done theory applies to product development at large—not just software products. While software engineers could certainly benefit from the new mindset, business owners and product managers may also want to use the same framework to think about higher level product and marketing strategies.
The Bottom Line
Job stories have become a popular alternative to user stories. By focusing on motivations, developers have greater context into customer problems. By decoupling problems from solutions, developers have the flexibility to find the best solution to fit a problem. Job stories also tie into the larger Jobs to Be Done theory of product development.
If you need help planning out your application, Sharkbyte’s Custom Development Roadmap can help you outline project objectives and tasks to keep everyone on track. Sharkbyte also provides Team Augmentation services to level up your development team as well as Custom Application Development to those that prefer to outsource development.