Abstract
In complex software and systems development, capturing user-centered yet technically actionable requirements is a persistent challenge. User stories, a popular agile technique, can falter in large-scale or intricate projects due to imprecision, lack of context, and poor traceability. Meanwhile, the Jobs-to-Be-Done (JTBD) framework focuses on the underlying “job” a user must accomplish, emphasizing why a solution is sought. Despite its promise for stable and innovation-driving requirements, JTBD alone remains abstract and not fully integrated into agile practices.
This article presents a novel methodology that synergizes user stories with JTBD for complex projects. A thorough literature review is conducted, carefully highlighting the strengths, limitations, and overall benefits of each approach. Next, an integrated framework is introduced, featuring diagrams, examples, and a comparative table. A concise case example demonstrates practical application. In conclusion, implications, limitations, and future research directions are discussed, aiming to enhance requirement clarity and alignment in complex software development.
Introduction
Modern software development often uses user stories to capture functional requirements in a concise manner with the format “As a [user], I want [capability], so that [benefit].” While effective for small features, user stories can struggle with complex systems, leading to backlogs that may lose context and traceability. Studies indicate that they are often poorly suited for large or intricate software projects.
Conversely, Jobs-to-Be-Done (JTBD) focuses on deeper user motivations by emphasizing the “job” a person hires a product to do, such as the famous example, “People don’t want a quarter-inch drill; they want a quarter-inch hole.” JTBD helps clarify why a product is needed but can lack direct application to software tasks.
Recognizing the strengths of both formats, experts suggest an integrated approach to address large-scale projects where user roles and motivations intersect. This paper proposes a structured methodology that combines user stories with JTBD, offering a hybrid model that retains agility while enhancing context, traceability, and alignment with user outcomes. By situating individual stories within overarching job statements, teams can better scale requirements, thereby creating robust, user-centered solutions that adapt to evolving business and user needs.
1 Literature review
1.1 User Stories in requirements engineering
User stories originated in agile methods like Extreme Programming and Scrum to replace lengthy requirements documents with concise, user-centered statements. Typically formatted as “As a [user role], I want [capability], so that [benefit],” user stories prioritize conversation and collaboration, often summarized by the “3 Cs”: Card, Conversation, Confirmation. Their brevity encourages continuous communication among developers, testers, and business stakeholders, allowing details to emerge just-in-time [1]. This approach aligns with fast-paced, iterative delivery, ensuring that each story provides visible user value.
In practice, user stories reside in a product backlog, prioritized by a product owner and selected for development sprints. They can be grouped into epics or themes to manage complex projects, although maintaining clear links to broader objectives can be challenging [2]. While the simplicity of user stories fosters understanding for both technical and non-technical team members, ambiguity may arise when supportive conversations are lacking. Moreover, scalability becomes an issue, as user stories focus on individual interactions without capturing how components fit together.
Traceability remains a challenge; informal and subject to change, user stories can be difficult to map to design or code, complicating compliance in long-term projects. Additionally, they often emphasize functional capabilities while neglecting non-functional requirements, limiting their effectiveness [3].
1.2 Jobs-to-Be-Done (JTBD) framework
JTBD (Jobs To Be Done) originated from innovation and marketing research, gaining prominence through the work of Clayton Christensen and Tony Ulwick [4]. It suggests users “hire” products for specific goals, shifting the focus from features to identifying underlying user needs or problems. The analysis typically employs a situation-motivation-outcome format: “When [situation], I want to [action], so I can [desired outcome].”
JTBD emphasizes deeper motivations, uncovering subtler user needs often overlooked by traditional methods. It encourages exploration of the reasons behind user actions, fostering innovation while remaining solution-agnostic, which allows for creative thinking aligned with true user outcomes. Notably, jobs are relatively stable over time, despite changes in products or technologies.
However, the implementation of JTBD can be abstract, lacking standardized methods to translate insights into actionable software tasks. Discovering jobs often requires intensive research, including interviews and observations, which can be complex in environments with overlapping needs [3]. Additionally, JTBD may overlook non-functional requirements, regulatory realities, or role-based distinctions among user segments.
In summary, user stories and JTBD present complementary strengths. User stories are effective for concrete, agile integration but may miss deeper contexts, while JTBD reveals motivations and outcomes yet can be challenging to implement. A hybrid approach combining JTBD and user stories may yield better results, injecting the “why” into agile requirements, and experts recommend using them together rather than treating them as mutually exclusive.
2 Proposed methodology: JTBD-enhanced User Story framework
An integrated methodology, called the JTBD-Enhanced User Story Framework (JUSF), combines the user story approach with Jobs-to-Be-Done principles to manage requirements in complex software development [5]. It utilizes Jobs-to-Be-Done for organizing requirements while user stories serve as actionable units for design. The framework features a dual-layer structure: the top layer consists of Job Definitions outlining high-level user goals, and the second layer contains User Stories linked to these jobs, ensuring traceability from development tasks to user needs. The process aligns with agile phases, including identifying jobs, forming job stories, and iterating on implementation (Figure 1).
Figure 1. Overview of the proposed JTBD-User Story integration process.
The steps of the framework are detailed below:
- Identify key Jobs-to-Be-Done
The process starts with a discovery phase to understand users' objectives through interviews, observations, and workshops. The focus is on identifying problems and desired outcomes instead of solutions. This phase leads to a set of jobs that users or stakeholders need to accomplish, categorized from ultimate jobs (e.g., “manage personal finances effectively”) to sub-jobs (e.g., “track expenses”). Establish success metrics for each job (e.g., “faster than the current process”). Jobs should be expressed in users' terms, avoiding technical details. Tools like JTBD interview techniques, such as the “Why?” laddering and context mapping, can facilitate this. In B2B contexts, include organizational goals as high-level jobs to define [6].
2. Formulate job stories
To effectively outline key jobs, articulate them as job stories using the JTBD format. A job story captures the context, motivation, and expected outcome in a narrative: “When [situation], I want to [motivation/goal], so that [expected outcome].” Alternatively, specify the user persona: “When [situation], [user persona] wants to [goal] so that [outcome].” Focus on user needs and context, not solutions [7]. For example: “When an employee submits a leave request, managers want an easy way to review and approve it so that the employee receives a timely decision.” Each job story functions as a parent requirement that may cover multiple functionalities and interactions, informing success criteria and contributing to a comprehensive Job Model.
3. Derive User Stories from Jobs:
After defining job stories, each is translated into one or more User Stories that guide development tasks. This process connects the problem space with actionable steps. The team analyzes each job story to brainstorm necessary features for the user to achieve their goals. The guiding question is: "What does the system need to accomplish this job story?"
User stories follow this format: As a [user], I want [feature], so that [benefit], ensuring clarity of the actor, action, and purpose. For example, from a job story about leave requests, user stories might include:
- As an employee, I want to submit a leave request online with all necessary details, so that the approval process starts quickly.
- As a manager, I want to be notified of new leave requests, so I can review them promptly.
- As an HR officer, I want approved leave recorded in the system, so payroll is updated correctly.
These stories address various roles involved in processing leave, ensuring a cohesive workflow. Non-functional requirements like performance (e.g., loading data within 2 seconds) and security (e.g., restricting access to managers and HR) are also considered. User Story Mapping visually organizes these elements, emphasizing completeness and collaboration among stories (Figure 2) [8].
Figure 2. A conceptual illustration of the relationship between a Job-to-be-Done
and its derived User Stories
4. Organize backlog
Organizing and prioritizing the backlog by jobs creates a two-level structure: a Job Backlog and a User Story Backlog. The User Story Backlog contains items ready for estimation and scheduling, while the Job Backlog supports release planning and prioritization. Grouping user stories by jobs offers benefits such as tracking progress and identifying gaps, allowing stakeholder prioritization at the job level to align with Minimum Viable Product (MVP) goals. This structure improves cross-team coordination and enhances integration testing. Additionally, linking jobs and stories in agile tools boosts traceability, making it easier to assess changes and outdated jobs. Each user story should reference its supporting job for context clarity during sprint planning.
5. Development and validation
Standard agile development involves designing, implementing, and testing user stories, focusing on validating increments against job outcomes rather than just acceptance criteria. During sprint reviews, the emphasis shifts to whether users can achieve their goals effectively. Once related user stories for a specific job are completed—possibly over multiple sprints—the product should undergo an end-to-end evaluation for that scenario, involving user acceptance testing or scenario simulations, like processing a leave request.
This structured testing identifies integration issues and demonstrates how the system supports user goals. If validation shows that a job isn't fully satisfied, feedback can lead to new or refined user stories. For example, if managers need a way to delegate approvals while on leave, this drives the creation of associated user stories. This iterative refinement process ensures alignment between desired outcomes and the means to achieve them, thereby addressing actual user needs in complex projects.
6. Continuous Job refinement
Jobs may evolve over time, necessitating periodic re-assessment of job stories. During product discovery phases for each release or every few sprints, the team should evaluate the relevance of identified jobs, considering whether new jobs have emerged or priorities have shifted. Keeping jobs explicit facilitates these discussions. For instance, usage data may reveal unexpected user goals, prompting the addition of new jobs to the backlog, or regulatory changes may introduce compliance-related jobs.
Cross-functional collaboration is essential throughout this process. Involving product managers, designers, developers, and QA in writing job stories and deriving user stories ensures that technical feasibility and UX considerations are addressed. This collaboration fosters a shared understanding of the motivations behind feature development, reducing silos within the team. Establishing a balanced cross-functional team is key to achieving better outcomes.
Comparison to traditional methods
To clarify how the proposed JTBD-Enhanced User Story Framework differs from and improves upon traditional approaches, Table 1 provides a comparison across key aspects. We contrast three approaches: using user stories alone, using JTBD (job stories) alone, and the integrated framework (JUSF) as described. This highlights how the methodology combines strengths and mitigates weaknesses.
Table 1. Comparison of the traditional User Story approach, the pure JTBD (Job Story) approach, and the proposed Integrated Framework across key aspects
|
Aspect
|
Traditional User Stories
|
Pure JTBD
|
Proposed integrated framework
|
|
Primary focus
|
Specific user role and feature (functionality to implement).
|
Underlying job (goal/motivation and outcome) with context.
|
Both role and context/goal. Maintains who for empathy and why for relevance in one cohesive structure.
|
|
Capturing the “Why”
|
Partially via the “so that…” clause, but often superficial. The true motivation may be assumed or lost.
|
Central – the entire job story is about why the user needs something. The motivation and outcome are explicit.
|
Explicitly captured at two levels. Job stories document the why and desired outcome; linked user stories inherit this context, ensuring every feature ties to a real user value.
|
|
Context of use
|
Typically omitted or minimal (e.g., no mention of when or conditions). Can lead to ambiguity in implementation context.
|
Explicit “When [situation]…” leads each job story, giving situational context.
|
Clearly specified at the job level (when/where the need arises) and propagated to stories. Reduces ambiguity – developers know the conditions under which each story’s feature will be used.
|
|
Level of detail
|
Very granular and implementation-friendly. Easy to estimate and develop each story, but might miss the big picture.
|
High-level and solution-agnostic. Great for vision but not directly implementable without further breakdown.
|
Multi-level: high-level job stories for vision and big picture; detailed user stories for implementation. Ensures big picture and small picture are both addressed and linked.
|
|
Handling multiple roles
|
Requires separate stories for each role, potential duplication if roles share goal (many “As a user…” stories). Roles are at the forefront even when they are not important.
|
Generally role-agnostic; focuses on a generic user need. Can overlook role-specific nuances, if any.
|
Accommodates multi-actor scenarios under one job. Different user stories for each actor can map to one job, preserving both common goal and role-specific tasks.
|
|
Non-functional requirements
|
Often neglected or written as separate technical stories; no inherent support in format.
|
Not explicitly covered; jobs usually phrased as functional outcomes.
|
Addresses them through job success criteria and additional stories per job (e.g., performance, security criteria for fulfilling the job). NFRs can be linked to relevant jobs for context (e.g., “fast checkout” ties to job “purchase product”).
|
|
Traceability & coherence
|
Low traceability (stories are independent cards). Coherence relies on epic linking or story mapping, which may be informal.
|
Coherent at vision level (all features tie to jobs conceptually) but no formal trace to code.
|
High traceability with hierarchical links (job-to-stories). One can trace each user story to a job (and vice versa) ensuring no story is an orphan and no job is unaccounted. Coherence is built-in: stories grouped by jobs form complete workflows.
|
|
Adaptability to change
|
Easy to reprioritize individual stories; difficult to assess impact on overall goals if scope changes.
|
Big changes in jobs can refocus product, but lacking intermediate plan, it’s a leap to adjust development.
|
Supports change at multiple levels. You can add/modify a job (then adjust its stories) or swap out stories while keeping job goals stable. If a job’s priority drops, all related stories can be deferred together. This provides structured adaptability.
|
|
Learning curve
|
Familiar to most agile teams; straightforward format. Potential misuse if team forgets conversations.
|
Requires training in JTBD thinking; not widely practiced in dev teams. Risk of misformulating jobs.
|
Moderate – uses familiar story practices augmented with JTBD. Initial effort to learn job framing, but maps well onto existing agile processes (backlog, sprints) so adoption is incremental.
|
The integrated approach (JUSF) aims to balance the clarity and implementability of user stories with the contextual depth provided by JTBD. Traditional user stories focus on tactical execution but can devolve into a mere checklist, detached from users' real goals. Conversely, JTBD offers strategic insights but lacks a practical application for daily development. This framework seeks to continuously align strategy with execution, addressing the inherent issues in user stories identified by Hyland—relevance, assumptions, and context—by ensuring each requirement is connected to its purpose, encouraging explicit discussions about motivations, and incorporating usage context [9].
3 Case example: hypothetical application in an enterprise system
To illustrate the proposed methodology, consider a hypothetical development project for a complex enterprise resource planning (ERP) system that includes modules for HR, finance, procurement, and serves various users. Traditionally, hundreds of user stories might be gathered for each module. However, the JTBD-enhanced framework starts by identifying key jobs the software must support.
A key job identified is: “Process Employee Travel Expense Reimbursements Efficiently.” This job is essential for the finance module and involves employees submitting expenses for reimbursement. Interviews reveal several pain points in the existing process: employees desire a simple way to submit receipts, managers require visibility into expenses, and accountants seek compliance to avoid late reimbursements. This leads to the following job story:
“When an employee incurs travel expenses, they want to get reimbursed quickly and correctly, so that they aren’t out-of-pocket for business costs and the company maintains proper financial records.”
From this job story, user stories are created, covering various system components, such as:
- Employees want to submit expense reports via a web portal.
- Employees want to track the status of submitted reports.
- Managers want to approve expense reports online.
- Accounting clerks want automatic policy compliance checks.
- CFOs want to view a dashboard of travel expenses.
Non-functional requirements include audit logging and mobile access for expense submission.
Using story mapping, these user stories are sequenced chronologically, revealing dependencies and ensuring completeness. This structured approach helps demonstrate the entire reimbursement process during sprints, allowing stakeholders to see user value.
If regulatory changes occur, the team can adapt by revisiting the job story, updating it, and deriving new user stories as needed, maintaining flexibility throughout the development process.
Conclusion
This article introduces a methodology for integrating User Stories with the Jobs-to-Be-Done (JTBD) framework to enhance requirements engineering in complex software development projects. The JTBD-Enhanced User Story Framework addresses limitations of both approaches by connecting high-level user jobs with detailed user stories. Job stories are introduced as an intermediate artifact, preserving the rationale behind requirements and ensuring they contribute to meaningful user outcomes. This hierarchical structure enhances coherence in development and mitigates feature buildup that lacks real-user relevance.
The framework is exemplified through a case study in an enterprise setting, demonstrating practical application and alignment of multiple user roles around a specific job, such as expense reimbursement. Benefits include improved prioritization, stakeholder communication, and product quality. Practitioners can adapt this framework to restructure backlogs and requirement workshops, fostering a deeper understanding of user jobs.
While the methodology is conceptually sound, its universal application remains to be validated. Challenges include potential organizational resistance to adding an extra layer of requirements and the need for training in writing effective job stories. Certain technical or regulatory requirements may also not fit into the job-story structure seamlessly. Adaptations may be necessary, and practitioners should exercise judgment in implementation.
References
- Atlassian. (n.d.). User stories – Examples and template. Atlassian Agile Coach. Retrieved April 11, 2025, from https://www.atlassian.com/agile/project-management/user-stories
- Kuhail, M. A., & Lauesen, S. (2022). User story quality in practice: A case study. Journal of Software Engineering Research and Development, 1(3). https://www.mdpi.com/2674-113X/1/3/1
- Lucassen, G., Keuken, M., Dalpiaz, F., Brinkkemper, S., Sloof, G., & Schlingmann, J. (2018). Jobs-to-be-done oriented requirements engineering: A method for defining job stories. In Requirements Engineering: Foundation for Software Quality (pp. 227–243). Springer. https://doi.org/10.1007/978-3-319-77243-1_14
- Christensen, C. M., Hall, T., Dillon, K., & Duncan, D. (2016). Know your customers’ jobs to be done. Harvard Business Review. Retrieved April 11, 2025, from https://hbr.org/2016/09/know-your-customers-jobs-to-be-done
- Cohn, M. (2024). Job stories offer a viable alternative to user stories. Mountain Goat Software. Retrieved April 11, 2025, from https://www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories
- Ulwick, A. (2023). Jobs-to-be-done – A comprehensive guide. Strategyn. Retrieved April 11, 2025, from https://strategyn.com/jobs-to-be-done/
- AWA Digital. (2022). Introduction to Jobs To Be Done. Retrieved April 11, 2025, from https://www.awa-digital.com/blog/jobs-to-be-done/
- Patton, J. (2024). User story mapping: Discover the whole story, build the right product. O’Reilly Media. Retrieved April 11, 2025, from https://www.crystalloids.com/insights/user-story-mapping
- Hyland, S. (2024). VMD Agile series – Job stories. VMD Corp Insights. Retrieved April 11, 2025, from https://vmdcorp.com/pages/vmd-agile-series-job-stories.html
Author: Nastassia Shahun, Senior Business Analyst
Nastassia Shahun is a Senior Business Analyst with 5+ years of experience bridging the gap between business needs and technology in Agile environments. She specializes in system analysis, user-centric design, and product strategy across domains like eCommerce, FinTech, and EdTech. Nastassia is also an international speaker, mentor, and contributor to the global BA community. She’s passionate about transforming product discovery and requirements engineering through practical frameworks that scale.