Skip to content
Browse
BABOK Guide
BABOK Guide
10. Techniques
Introduction 10.1 Acceptance and Evaluation Criteria 10.2 Backlog Management 10.3 Balanced Scorecard 10.4 Benchmarking and Market Analysis 10.5 Brainstorming 10.6 Business Capability Analysis 10.7 Business Cases 10.8 Business Model Canvas 10.9 Business Rules Analysis 10.10 Collaborative Games 10.11 Concept Modelling 10.12 Data Dictionary 10.13 Data Flow Diagrams 10.14 Data Mining 10.15 Data Modelling 10.16 Decision Analysis 10.17 Decision Modelling 10.18 Document Analysis 10.19 Estimation 10.20 Financial Analysis 10.21 Focus Groups 10.22 Functional Decomposition 10.23 Glossary 10.24 Interface Analysis 10.25 Interviews 10.26 Item Tracking 10.27 Lessons Learned 10.28 Metrics and Key Performance Indicators (KPIs) 10.29 Mind Mapping 10.30 Non-Functional Requirements Analysis 10.31 Observation 10.32 Organizational Modelling 10.33 Prioritization 10.34 Process Analysis 10.35 Process Modelling 10.36 Prototyping 10.37 Reviews 10.38 Risk Analysis and Management 10.39 Roles and Permissions Matrix 10.40 Root Cause Analysis 10.41 Scope Modelling 10.42 Sequence Diagrams 10.43 Stakeholder List, Map, or Personas 10.44 State Modelling 10.45 Survey or Questionnaire 10.46 SWOT Analysis 10.47 Use Cases and Scenarios 10.48 User Stories 10.49 Vendor Assessment 10.50 Workshops

7. Techniques

7.4 Job Stories

Agile Extension to the BABOK® Guide

7.4.1 Purpose

Job Stories are used to represent a product backlog item (PBI) or requirement in terms of a job to be done by a stakeholder.

Job Stories focus on the motivation of the stakeholder and provide as much context as possible for the motivations, anxieties, and struggles of the stakeholder. They add contextual information that can affect how a stakeholder wants a desired feature to be and enables helps with making the right implementation decisions.

Job Stories also serve as a communication tool for stakeholders. They facilitate interaction and collaboration among individuals and focus the delivery team on the customer need, while leaving implementation details to be determined.

.1 Format

A job story follows a specific format. It can be written in first person or third person format.
A job story can be formatted as follows:

When <situation> I want to <motivation> so I can <expected outcomes>

When someone <situation>, actor(s) <motivation> so that <expected outcomes>

Example

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.

.2 Situation

The first element of the job story syntax is situation.

Situation provides context for when the job needs to be completed. The context of the situation encourages the delivery team to think of a wide variety of possible solutions. The more context provided, the better the delivery team can design the solution.

When there are multiple roles that would complete a job, those roles are included in the “when” statement.

The persona is not included in the situation specifically so the delivery team can focus on real customers.

.3 Motivation

The second element of the job story syntax is motivation.

Motivation focuses on the customer motivation. It can include internal and external forces for motivation.

Desired features or solutions are specifically not included in Job Stories in order to focus on the customer.

.4 Expected Outcomes

The third element of the job story syntax is expected outcomes.

The outcome should satisfy or alleviate the motivation which prompted the situation.

.1 Strengths

  • This format reduces assumptions regarding the role and removes the persona biases.

  • It can be set up for cause and effect scenarios.

  • This format focuses on stakeholder motivations instead of defining implementation.

  • It is helpful for user experience design.

  • Teams find it easier to empathize with the stakeholder.

  • Removes focus on features and instead focuses on the stakeholder's desired future state.

  • Teams can use Job Stories and User Stories together on backlog. The job story indicates the motivation and outcome for the stakeholder, while the user story indicates features that could solve the problem.

.2 Limitations

  • This format has a tendency to be more verbose than User Stories because of the context, roles, and outcomes included.

  • Job Stories can decompose into multiple smaller Job Stories which require management through refinement and prioritization.

  • If Job Stories and User Stories are both on the product backlog, teams can get confused when switching between formats.

Techniques From the BABOK® Guide

1-10

11-20

21-30

31-40

41-50