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, one of the key frameworks scrum teams can use to focus on customer needs.
Job stories have become a popular alternative to user stories that focus on customer motivations while decoupling solutions. Click To TweetWhat’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).
User Stories in Agile Development – Source: Atlassian
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. When creating your software roadmap, 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.
Job Stories Should Be Independent of Solutions – Source: JTBD
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, product managers and scrum masters 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 from the first sprint planning meeting. 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.
FAQ about Job Stories vs User Stories
The role of a scrum master in managing user stories and job stories is to facilitate the Agile process, ensuring that the team adheres to the principles and practices of Agile development. The scrum master supports the team by removing any obstacles that may hinder their progress, fostering effective communication and collaboration, and coaching team members on how to create and manage user stories and job stories effectively. This involves assisting the product owner in refining and prioritizing the backlog, guiding the team in breaking down complex tasks into manageable units, and promoting a focus on delivering valuable, working software in each sprint.
The Agile meaning in the context of user stories and job stories refers to the iterative and incremental development approach that focuses on delivering customer value through collaboration and continuous improvement. User stories and job stories are Agile artifacts that help teams understand customer needs, prioritize work, and define the desired outcomes of their efforts. By using these tools, Agile teams can remain flexible and responsive to changing customer requirements, ensuring that the features they develop are aligned with customer goals and motivations.
Scrum master jobs may differ when focusing on job stories rather than user stories due to the shift in perspective from predefined solutions to understanding customer motivations. When working with job stories, scrum masters need to emphasize the importance of gathering real customer insights, analyzing the underlying motivations behind customer actions, and encouraging the team to explore multiple potential solutions. This may require additional coaching, facilitation, and support to help the team adapt to the new mindset, as well as collaboration with the product owner to ensure that the backlog accurately reflects customer needs and priorities.
Using job stories in a scrum project offers several key benefits compared to user stories, including:
- A deeper understanding of customer motivations, leading to more effective product development
- Encouraging exploration of multiple solutions, fostering innovation and creativity
- Reduced reliance on assumptions, minimizing the risk of developing features that don't meet customer needs
- Promoting a customer-centric mindset, ensuring that the team's efforts remain focused on delivering customer value
- Facilitating more productive discussions and collaboration among team members, as they work together to understand and address customer goals and challenges.
Agile artifacts, such as user stories and job stories, play a vital role in the Agile process by providing a structured format for capturing and communicating customer needs, goals, and motivations. These artifacts help teams maintain focus on delivering customer value by breaking down complex projects into manageable tasks, prioritizing work based on customer impact, and ensuring that the team's efforts align with the desired outcomes. Additionally, user stories and job stories facilitate collaboration and shared understanding among team members, fostering a customer-centric mindset that enables more effective product development.
The composition of a scrum team can significantly influence the creation and management of user stories and job stories. A well-balanced team consisting of diverse skill sets, experiences, and perspectives can contribute to a richer understanding of customer needs and motivations. This diversity allows for more effective brainstorming, problem-solving, and decision-making, resulting in better-crafted user stories and job stories that accurately reflect customer goals. Additionally, clear communication and collaboration among team members are essential for managing these artifacts, ensuring that everyone understands the desired outcomes and works together to achieve them.
A sprint backlog consisting of user stories focuses on specific actions and predefined solutions, while one with job stories emphasizes customer motivations and leaves room for exploring various solutions. User stories tend to be more prescriptive, outlining the desired functionality based on assumptions about what the customer needs. In contrast, job stories encourage teams to delve deeper into the underlying motivations behind customer actions, allowing for a more comprehensive understanding of the problem and potential solutions. This shift in perspective can lead to more innovative and effective product development, as teams are encouraged to think beyond the initial assumptions and consider alternative approaches.
Scrum artifacts, such as the product backlog, sprint backlog, and increment, can help facilitate the transition from user stories to job stories by providing a structured framework for capturing, prioritizing, and managing work items. As teams adopt the job stories approach, they can revise and refine these artifacts to better reflect the customer motivations, context, and desired outcomes. This may involve updating the product backlog with new job stories, re-prioritizing work items based on a deeper understanding of customer needs, and tracking progress toward achieving the outcomes defined by the job stories.
Yes, there are agile coach jobs remote that focus on teaching teams how to use job stories effectively. These coaches typically have extensive experience in Agile methodologies and a deep understanding of the Jobs to Be Done theory. They provide remote guidance, training, and support to help teams transition from user stories to job stories, emphasizing the importance of understanding customer motivations and exploring multiple solutions. This may include conducting workshops, providing one-on-one coaching, and offering resources to help teams adopt the job stories approach and improve their product development process.
The scrum master salary may vary depending on experience, location, and the specific responsibilities within a given organization. Generally, a scrum master salary is competitive with that of a product owner or developer, as each role contributes unique expertise and value to the Agile process. A scrum master who specializes in managing user stories and job stories may command a higher salary if their skills are in high demand, as this expertise can lead to more effective product development and improved customer satisfaction.
