Search the site:

Browse topics

Browse these topics:

Job Stories Offer a Viable Alternative to User Stories

Job Stories Offer a Viable Alternative to User Stories

Mike Cohn

  • product backlog
  • user stories
  • job stories

User Story Examples - Download Now!

Get 200 Real Life User Stories Examples Written by Mike Cohn

Enter your email address below to get over 200 user stories from three complete product backlogs created by Mike Cohn.

Email Address

We hate spam and promise to keep your email address safe. Unsubscribe at any time. Privacy Policy

As useful as user stories can be, they’ve never been right for every team. An exciting alternative for some teams is the job story . A job story is focused less on the user performing some function than on the job to be done by that story. Job stories originated at Intercom and were best explained by Alan Klement .

A Job Story Template

To see how a job story shifts emphasis from the user to a job to be done, let’s take a look at the recommended job story template:

how to write job stories

As with the common user story template , there are three parts to complete in the job story template. The first is known as the situation . This follows the word when in the template and provides context on when the story is being performed or perhaps what triggered the story. Examples could be:

  • When an order is submitted…
  • When searching by postal code…
  • When no matches are found…
  • When looking at recent orders...

The second element of the job story template follows the I want to and provides the motivation for the story. Think of the motivation as a user’s stated or first-order goal.

As an example, I want pizza for dinner tonight. Why do I want pizza tonight? Because I am meeting some friends tonight to watch a football game, and it’s easy to feed a group of us with different dietary needs and preferences with pizza. In the job story world, easily feeding a group is referred to as the expected outcome and it follows the so I can portion of the template.

Putting my desire for pizza into a job story would lead to

  • When it’s dinner time tonight, I want to have pizza so I can easily feed my friends.

This isn’t a particularly perfect job story, but it illustrates the difference between a user’s motivation and their expected outcome.

Contrasting Job and User Stories

To see the times when job stories may be better than user stories, let’s look at some sample job stories and their corresponding user stories.

When an Order Is Submitted...

Let’s start with this job story:

Job Story: When an order is submitted, I want to see a warning message so I can avoid resubmitting the order.

This story describes the behavior seen on most eCommerce sites warning a user not to submit an order multiple times.

The user story equivalent of this might have been

User Story: As a customer, I want to be shown a message telling me not to submit an order twice so that I don’t place a duplicate order.

The job story is superior in this case for two reasons. First, this story applies to everyone making a purchase on the site. So it’s not important to know the person doing this is a customer. (In fact, calling the person a customer could be misleading because the person may not be a customer until this order has been placed.)

Second, the job story is better because it provides more context about when this is happening. It is happening “when an order is submitted,” as the job story tells us. Look carefully at the user story and you’ll notice that it never tells us when this message is displayed. The team could “successfully” implement the user story by adding an item on an FAQ page warning against double submitting orders. That is almost certainly not what the product owner wants.

Let’s look next at a job story about searching for an address by United States ZIP (postal) code.

Job Story: When searching by US ZIP code, I want to be required to enter a 5- or 9-digit code so I don’t waste time searching for a clearly invalid postal code.

This story is about making sure a user enters something reasonable for a postal code before allowing a search. The United States postal, or ZIP, codes are either 5 or 9 digits. This story says users should be prevented from clicking search with only entering two letters entered in the postcode field.

The equivalent user story would be:

User Story: As a user, I want to be required to enter a 5- or 9-digit postal code so I don’t waste time searching for a clearly invalid postal code

These two stories highlight that the difference between user and job stories exists in the first part of the templates. The when… and As a … clauses differ but in this example, the remainder of each story is identical in both user and job story format.

As in the first example, the job story is better here because of the additional context it provides around when the story is being performed. Who is performing the action (the search in this case) is not important, which is why the user story is written with the generic, “As a user…”

When to Use Job Stories

In deciding when to use job stories, I think it’s important to acknowledge that both user and job stories have unique strengths.

I still find user stories most helpful for products that have users who vary significantly and deeply understanding those users is important. This is why user stories start with As a… We start user stories that way because that puts the user right upfront. With user stories, who will be doing the story is perhaps as important as what they’ll be doing.

In contrast for a job story, it is not necessarily important who is doing the story. This makes job stories the better option when your product has users but their needs are not very distinct.

If you’ve ever written a lengthy set of user stories and started each with “As a user…”, you’ve encountered this problem. When a large set of user stories all begin with “As a user…” you’ve got a set of stories for whom the user is not very important.

Writing those as job stories rather than user stories would be helpful. Doing so would allow the story to include the additional context of when the story is being performed. In some cases, knowing when a story might happen is more important than knowing who will perform it.

Combining the Strengths of Job and User Stories

So, while job and user stories each have their own strengths, it’s possible to merge them and get both benefits in one story. Let’s revisit our postal code stories and see how to do this. First, we had the job story:

Job Story: When searching by postal code, I want to be required to enter a valid code so I don’t waste time searching for a clearly invalid postal code.

It’s never clear who is performing this story. Is it a normal user? A site admin? Someone else? We’re never told. If we think knowing who is doing this is important, we can augment the job story by adding a role to the story in place of I. This changes our story to be the following:

Job Story: When searching by postal code, a buyer wants to be required to enter a valid code so the buyer doesn’t waste time searching for a clearly invalid postal code.

The changes are in bold. You can see that I just changed from “I want…” to “a buyer wants…” and then made the corresponding change later in the story.

We can do something similar to a user story. Our initial, unmodified story was:

User Story: As a user, I want to be required to enter a valid postal code so I don’t waste time searching for a clearly invalid postal code

To provide additional context, we add a phrase telling us when the user is doing this. Our modified user story then becomes “

User Story: As a user who is searching by postal code , I want to be required to enter a valid postal code so I don’t waste time searching for a clearly invalid postal code

The modified user and job stories are semantically the same. Which you choose is entirely up to you. I personally prefer the modified user story over the modified job story because it keeps the story in first person. I’ve written elsewhere about the benefits of stories being in the first person .

So when should you prefer user or job stories over the other?

First, each is great and has its own advantages. During the course of any week, I will write some user stories and some job stories. The two techniques are quite compatible and there’s no reason to view them as mutually exclusive.

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.

A good starting point is to mix user and job stories in the same product backlog. Start by writing job stories any time you are tempted to write a batch of stories all beginning with “As a user…”

What’s Your Experience?

What do you think of job stories? Would they be helpful on your product backlog? Have you worked with job stories before? Were they helpful? Please share your thoughts in the comments section below.

See user stories Mike Cohn wrote as part of several real product backlogs.

You may also be interested in:

Definition of Ready: What It Is and Why Its Dangerous

Definition of Ready: What It Is and Why Its Dangerous

User Story Template: What It Is and Why It Works So Well

User Story Template: What It Is and Why It Works So Well

Agile Requirements Gathering: Three Types of Requirements

Agile Requirements Gathering: Three Types of Requirements

User Stories: How to Create Story Maps

User Stories: How to Create Story Maps

How to Run a Successful User Story Writing Workshop

How to Run a Successful User Story Writing Workshop

What Are Agile Story Points?

What Are Agile Story Points?

how to write job stories

  • The Magazine
  • Newsletters
  • Managing Yourself
  • Managing Teams
  • Work-life Balance
  • The Big Idea
  • Data & Visuals
  • Reading Lists
  • Case Selections
  • HBR Learning
  • Topic Feeds
  • Account Settings
  • Email Preferences

The Key to Landing Your Next Job? Storytelling.

  • Janine Kurnoff
  • Lee Lazarus

how to write job stories

Recruiters may think they make decisions based purely on logic, but their feelings play just as large of a role. Emotions drive how connected we feel to other people, and those connections lead us to perceive someone in either a positive or a negative light. The quickest way to land on the “positive” side of that equation is simple: Tell a good story on your resume, in your cover letter, and during your interview.

  • Begin with your audience in mind. What is their role? What is their level? What’s going on with their business and their industry? What current challenges are most important to them?
  • Now, craft a narrative — both through the accomplishments you include on your resume and through the message you write in your cover letter.
  • Provide context to establish how what you bring to the table as a candidate is perfect for the challenges and needs their company is looking to hire for.

Four tips that will help you get noticed (and get ahead) in your career.

Ascend logo

Where your work meets your life. See more from Ascend here .

Today’s workforce is hyper-competitive. It’s hard to stand out, and if you’re hunting for a job, you need strategies to appear more credible, authentic, and memorable than your peers.

  • JK Janine Kurnoff is the co-founder and chief innovation officer at The Presentation Company (TPC) and co-author of the bestselling book, Everyday Business Storytelling . She and her sister, Lee, founded TPC in 2001 after seeing talented businesspeople miss opportunities to sell their ideas because their messages lacked clarity, authenticity, and meaning. TPC’s workshops provide innovative solutions to help people clearly communicate the value of their message and inspire conversations that drive action.
  • LL Lee Lazarus is the co-founder and chief revenue officer at The Presentation Company (TPC) and co-author of the bestselling book, Everyday Business Storytelling . Together with her sister, Janine, and their team, TPC has devoted the past 20 years to helping some of the world’s top brands—such as Facebook, Nestle, Medtronic and Hewlett-Packard—create captivating, results-oriented business communications.

how to write job stories

Partner Center

how to write job stories

Replacing The User Story With The Job Story

Too many assumptions are dangerous.

Alan Klement

Alan Klement

Jobs to be Done

I’ve written about the problem with user stories before . At the time, I found it better to just have the team talk over proposed changes to the product. This worked great when the team had gelled and the product is very mature; however, now I’m working with a new team and building a product from scratch. In this case, because our canvas is blank, we are having trouble getting on the same page when it comes to customer motivations, events and expectations. But today, things have turned around. I’ve come across a great way to use the jobs to be done philosophy to help define features. I call them Job Stories.

Where It Comes From

The idea comes from the really smart people at intercom . Here is what is they say:

We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome: When _____ , I want to _____ , so I can _____ . For example: When an important new customer signs up, I want to be notified, so I can start a conversation with them.

It’s not referred to as a Job Story in the article, but I’ll call it that so I can easily reference it in the future. The article doesn’t spend a whole lot of time with the concept, so I’ll talk about why I like it and why it’s better than User Stories.

The Problem (Again) With User Stories

Summed up, the problem with user stories is that it’s too many assumptions and doesn’t acknowledge causality. When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there’s no room to ask ‘why’ — you’re essentially locked into a particular sequence with no context.

Here’s how I see the format:

The first problem is that we start with a Persona, which is a very bad idea , and then plop in an action which we think should be taken in order to achieve the expected outcome. As I’ve marked in the above image, there’s really a disconnect between the action and persona. Here, let’s look at some existing User Stories:

In the above chart, when someone reads moderator or estimator is that really adding anything? If anything it’s adding ambiguity to the flow. You and I are going to attach our own interpretation of what a moderator is or why they are in these particular contexts.

Here, try this. Chop off the whole As a / an segment and see if you’re really losing anything. Compare these two:

As a moderator I want to create a new game by entering a name and an optional description

I want to create a new game by entering a name and an optional description

Did the sky fall?

The Job Story : All About Context and Causality

Update: 2015–03–03: Based on even more usage & feedback, I use a slightly different explanation now. See these tweets of how I suggest framing it now . An update of this article will come in the future…

Check out the image above. Now we’re cookin’!

All of the information above is critical and very informative because we’re focusing on causality. Each job story should provide as much context as possible and focus on motivation… instead of just implementation.

[update June 4th 2014] After working with Job Stories for a while now, I’ve changed ‘Motivations’ to ‘Motivations and Forces’. Look to 5 Tips For Writing A Job Story which touches on this. Also learn more about the forces via this podcast and this short article .

Let’s rewrite some examples from the user story chart above as a Job Story and add motivation and context to each one.

User Story:

As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.

When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.

As an estimator, I want to see the item we’re estimating, so that I know what I’m giving an estimate for.

When I find an item I want to set an estimate for, I want to be able to see it, so that I can confirm that the item I’m estimating is actually the correct one.

As a moderator, I want to select an item to be estimated or re-estimated, the team sees the item and can estimate it.

When an item does not have an estimate or has an estimate I’m not happy with, I want to be able to restart the estimation process and notify everyone, so that the team knows a particular item needs to be estimated upon.

What About Multiple Roles & Events?

*Added July 28th 2014

As I get great feedback regarding Job Stories and as I continue to work with Job stories, I’ve found that sometimes it’s helpful to include Roles, or Characters , as part of the When_ clause.

Products With Multiple Roles

Roles / Characters are most helpful when the product has multiple roles, e.g. an IT product ( Admin, Manager, Contributor….) or in a marketplace product product ( Buyer , Seller ). The reason is just to clarify who we’re talking about.

Using eBay as an example:

When a Buyer has already made a bid on an item, they are anxious about missing a counter bid and want to immediately receive counter bid notifications, so they can have enough time to evaluate and update their own bid.

Roles With Cause & Effect

Sometimes, there are situations when a Job Story effects multiple roles at once — setting up a cause and effect scenario.

Using eBay, again, as an example:

When a Seller isn’t happy with the bids they are getting and takes their product off the market, Buyers who have already submitted bids, want to be immediately notified that the product has been pulled, so that Buyers know they no longer need to keep tabs on the product and should look for a different, similar product instead.

Using Events Instead Of Roles

Sometimes, however, there might be a situation when an event effects all the roles or groups of roles: such as needing to get a password reminder. In this case there’s no reason to have a specific role, rather, try to keep it event based and general by using terms like customer or someone ( but not user ):

When a customer is on their mobile device and forgets their password, they want to get their password in a way that makes it easy to reclaim it via their mobile device, so they can continue to log in and access their news feed.

Why not user ? User feels very lifeless and sterile, instead, customer reminds us that we have people who need to be served and respected.

Define Motivations, Don’t Define Implementation

Job Stories are great because it makes you think about motivation and context and de-emphasizes adding any particular implementation. Often, because people are so focused on the who and how , they totally miss the why. When you start to understand the why, your mind is then open to think of creative and original ways to solve the problem.

Your Job Story Needs A Struggling Moment , 5 Tips For Writing A Job Story .

Get a deeper understanding of JTBD and Job Stories from my book When Coffee and Kale Compete .

You can download it as a free PDF, or buy it in paperback & kindle right here . You can also read it online here .

If you have more questions about Jobs to be Done, or want help applying JTBD concepts to your business or startup, contact me .

Alan Klement

Written by Alan Klement

I help businesses become great at making and selling products that people will buy. Contact me:

More from Alan Klement and Jobs to be Done

What is Jobs to be Done (JTBD)?

What is Jobs to be Done (JTBD)?

Upgrade your user, not your product. don’t build better cameras — build better photographers..

Know the Two — Very — Different Interpretations of Jobs to be Done

Know the Two — Very — Different Interpretations of Jobs to be Done

The popularity of jobs to be done has exploded in recent years. this has been both good and bad..

When You Define Competition Wrong

When You Define Competition Wrong

Too “kool” for school — why did the chotukool flop — the mainframe versus the pc — don’t be fooled by randomness — put it to work.

5 Tips For Writing A Job Story

5 Tips For Writing A Job Story

Learning from a new way to define features and products., recommended from medium.

JTBD Framework

Jayendra More

Why Jobs to be Done Framework is a Game-changer for Product Development

Discover how the jobs to be done framework can revolutionize your product development process and create solutions that truly meet customer.

UX/UI Design Trends Going Into 2024

Punit Chawla

UX/UI Design Trends Going Into 2024

Every year, we have a line up of new design trends that not only look good, but also stick around and influence other designers to “steal”….

how to write job stories

Good Product Thinking

how to write job stories

A Guide to OKRs – Objectives and Key Results

how to write job stories

Growth Marketing

These Words Make it Obvious That Your Text is Written By AI

James Presbitero Jr.

Practice in Public

These Words Make it Obvious That Your Text is Written By AI

These 7 words are painfully obvious. they make me cringe. they will make your reader cringe..

Miller’s law graphic showing the human brain taking a bunch of words, chunking it into smaller bots and rembering only 7 plus or minus 2 words.

Ross Dillon

The Most Influential Psychological Studies on UX Design.

Understanding how the human brain works helps us build designs that work for humans..

Jobs-To-Be-Done: Uncover Your Customers’ Hidden Needs In 4 Steps

Sara Landi Tortoli

Product Coalition

Jobs-To-Be-Done: Uncover Your Customers’ Hidden Needs In 4 Steps

Including free access to a customized jtbd gpt and printable checklist, this is the only guide you’ll ever need for your product discovery..

Image showing the Threads logo falling off a cliff.

Daniel de Mello

UX Collective

The UX of Threads’ downfall

When fast onboarding gets in the way of long-term retention..

Text to speech

User and job stories

Write user or job stories that describe why and how a user interacts with your service or information.

Why create user and job stories?

Your stories will help to build out the foundations for defining iterations and services that lead to creating content.


You'll need to know:

  • who your users are
  • their pain points when they access your service or website

This data will be in your user research findings.

  • index cards

How to create user job stories

Step 1: use pain points to write your stories.

Once you have collected your user pain points you can write your stories in response to them. Jot them on an index card so you can visualise and group your stories.

The most common format for a user story is:

  • As a … (who is the user: be as specific as possible)
  • I want to / need to … (what task is the user trying to do)
  • So that … (why does the user want to do this task and what is their goal)

For example:

  • As a young person entering the workforce for the first time
  • I need to know what I should be getting paid (minimum wage)
  • So that I can negotiate/check this with my employer

Step 2: Start broad, then get detailed

Keep your stories simple, focused, concise and active. Begin with broad stories by focusing on the overall goal. Then gradually break this down to create stories that reflect an individual task.

For example, an overarching story might be:

  • As a content designer
  • I need to create user-centred content
  • So that my content meets a user need

A more detailed task-based user story under this could be:

  • I need to understand readability requirements
  • So that my content is clear and accessible to people with low literacy levels

Step 3: Work out if you need job stories

Job stories can be used when you have the same user/s for each story and your stories are starting to sound repetitive. A job story helps you create more detail.

Job stories follow the format:

  • When … (what situation is the user in)
  • I want to … (what is the user trying to do or need)
  • So … (what is the user’s goal)

For the readability example above, the user is a content designer and the job story could be:

  • When I am creating content
  • I want my content to be written simply
  • So that people with lower literacy levels can understand it

Step 4: Write acceptance criteria

Write acceptance criteria on the back of your index cards to measure how your content meets a user or job story. When you meet the acceptance criteria you have completed the story.

For our readability example in the user story above, acceptance criteria might be that:

  • content is in plain English
  • content was tested with a readability tool and scored between a Year 5 (around age 9) and Year 9 (around age 13) reading level
  • content is tested for comprehension with users Acceptance criteria should state a high-level intent, rather than a solution. Use acceptance criteria to test your content and measure performance.

Step 5: Map your stories

Map your user story cards in a tree format. Start with the broad overarching stories at the top of the tree and then map more specific user needs below this.

Group related tasks together so you can visualise how the content may fit together to meet a certain need.

Mapping your needs will also help you outline your minimum viable product (MVP). This shows the minimum stories you need to work to for the content to meet the overall goal.

By prioritising content this way, you can create an MVP for testing. Everything not prioritised can go in your backlog to work on later.

Example of a user story map

This is the user story of a content specialist. Highlights what the user needs to know (their pain points), and what the related tasks are that they're trying to achieve.

Step 6: Write content to match your user stories

Once you have a detailed story map you can create content that aligns with your stories.

Traditionally, in an Agile team, developers use user stories to create tasks for each sprint. User stories can also help provide the structural outline to your content.

Your content should meet the acceptance criteria for a story. This is so your content meets a user need.

Get your team to practise writing user stories to begin to change their way of thinking. This will help them understand content design and to put the user first.

Use your user stories to align the team and work towards the same goal.

Share user stories with stakeholders to remind them of the user need behind the content, and the content’s purpose. You can use user stories to get empathy, trust and buy-in from decision makers.

While you’re creating content, keep referring back to your story map to stay on track and remember what the user needs to know.

Your user story map reflects a broader user journey. It may also show how you can ‘join up’ disconnected or contradictory content across different business areas.

Testing may highlight that your user stories or job stories need to be iterated. User needs change, so stories have to adapt to this

  • Jeff Patton:  User story mapping
  • GOV.UK:  Writing user stories

© Commonwealth of Australia. With the exception of the Commonwealth Coat of Arms and where otherwise noted, this work is licensed under the CC BY 4.0 license.

Social media

  • Get the Digital Profession newsletter
  • APSC website

Oct 25, 2021 · 6 min read

User Stories vs. Job Stories: What’s Right for You?

by Małgorzata Maksimowicz

User Stories

Empathy is central to most design and development processes. Empathy maps help UX designers better understand a user's state of mind when trying to accomplish a task and, similarly, developers employ user stories to provide context for software requirements.

Of course, user experience design is constantly changing, and there's no shortage of novel approaches to understanding the users. In that regard, job stories have become a popular alternative to user stories as they can add more context to proposed features, enabling developers to explore the best ways to help users accomplish a given task.

Let's take a look at the difference between user stories and job stories and how to decide on the best option for your business.

Copy link What are user stories?

User Stories are non-technical explanations of a software feature written from the end user's perspective. The goal is to understand  why  the feature is necessary and the value it has for users, rather than just a technical scope of work.

The general formula for a User Story is:

"As a [persona], I want to [action], so that [expected outcome]." For instance , "As a sales professional, I want to share notes with my colleagues, so we can more effectively close a sale."

Why write user stories?

Product managers write user stories, and the team decides what stories they'll take on during the sprint planning meeting. In addition, teams may estimate the difficulty of user stories using planning poker or other strategies. It makes it easier for the team to ensure that they can realistically complete their story commitments during a sprint.

User Stories (Jira)

Atlassian’s Jira makes it easy to organize user stories in a backlog. Source:  Atlassian

User Stories are helpful for several reasons:

They focus on the customer rather than the technical specification. That way, you’re less likely to develop a solution that doesn’t match an actual customer need.

They encourage collaboration between design and development teams to arrive at the best possible outcome rather than keeping them isolated from each other.

They spark creative solutions that may not otherwise arise with strict technical specifications.

They create momentum by showcasing actual user-centric accomplishments rather than a checklist of technical tasks with no broader context.

A common criticism of User Stories is that they make some fundamental assumptions. In particular, the "I want to" statement assumes that it is the best action to take . As a result, the team cannot think outside the box when reading the user story because there's no other context, such as the user's actual motivation for wanting the feature.

Copy link Improving with Job Stories

Intercom  came up with the idea behind Job Stories, and  JTBD  ultimately refined the concept and gave it a name. According to Intercom, rather than focusing on what users want to accomplish, Job Stories frame every design problem as a job focusing on the triggering event or situation , the motivation and goal, and the intended outcome.

The general formula for a Job Story is:

"When I [situation], I want to [motivation], so I can [expected outcome]." For example, " When I want to find out more about a sales lead, I want to see conversations my colleagues had with a lead in the past, so I don't have to ask them."

Use Job Stories for additional context

Compared to the earlier User Story, the Job Story provides more context as to why the user wants chat functionality in the application . In particular, the user's pain points are much more visible than a User Story could show — and the team can focus on designing to eliminate that pain.

When writing job stories, product managers should provide as much context as possible , focusing on the motivation behind the feature rather than the implementation details. As a result, development teams may identify better ways to accomplish the job than the proposed implementation in a Job Story.

Copy link What's right for your team?

The decision between User Stories and Job Stories depends on your business and team dynamics. For example, if you have a mature product and team, you may not need Job Stories or User Stories to empathize with your users. However, if you have a new team or product, these stories can help your team better understand the user.

When to choose User Stories?

User Stories tend to work best in companies with rigid software requirements . If you don't have flexibility in building a feature, user stories can help provide customer-centric thinking without deviating from the desired specification. However, if you have flexible requirements, Job Stories are better to help the team consider problems from every angle.

When to choose Job Stories?

Job Stories are the most useful when you're already taking a Jobs to Be Done (JTBD) approach. Unlike activity-centric design that focuses on tasks like "store a file," JTBD focuses on customer transformations, like "keep a safe backup copy in the cloud." Of course, you're storing a file in both instances, but keeping a safe backup is the driving customer motivation.

Copy link Tips to better understand your users

Job Stories and User Stories are just two tools you can use to better empathize with and understand users . There are many other strategies that user experience designers, product managers, and developers can use to ensure that they're on the right track with creating the product. Some popular tools include:

User Personas  are detailed profiles of potential or existing customers that explore their personalities, influences, expertise, goals, devices, relationships, and other information. Most teams use multiple personas to reflect different types of users.

Empathy Maps  explore what users are thinking or feeling at various points when accomplishing a task. They may also detail users' pain points and what they're saying or doing when using the product to provide greater context.

Journey Maps  are visual stories of a customer's interaction with your product. It provides insight into common customer pain points along the way and a template for running experiments to determine whether workflows will be successful.

User Interviews  can help provide valuable insights into user thoughts and actions when you have a prototype ready. For instance, you may watch a user navigate an application while talking through their problem.

Copy link Summary

Job Stories aim to provide more context than User Stories —and you can use them in the same way throughout the Agile development process. They work best when paired with other customer-focused development practices, such as JTBD, but you can also use them as a strict substitute to promote outside-the-box thinking by developers.

If you need help reaching product-market fit, Intent can help you with everything from pre-development research to marketing and maintenance.  Contact us for a free consultation !

Małgorzata Maksimowicz UX Designer

Małgorzata Maksimowicz

UX Designer

Related Articles

intent sp. z o.o

00-679 Warsaw

See on map Open Google Maps

Privacy Policy

Cookies Policy

Product Design

Product Development

how to write job stories

© 2008– 2024 intent

  • Success Stories
  • Discover & Frame Workshop
  • Full Cycle Product Development
  • Design & Product Consultancy
  • App Development
  • Cloud & DevOps
  • Data & Analytics
  • Software testing
  • Technology Consulting
  • Legacy Modernisation
  • Enterprise Mobility
  • Dedicated Teams
  • Offshore Development Centre
  • Ecommerce & Retail
  • Supply Chain
  • Financial Services
  • Consumer Internet
  • Healthcare & Pharma
  • Loyalty & Rewards
  • Real Estate
  • Travel & Transportation
  • Mobility COE
  • Data Science COE

Dew Solutions

Dew Solutions specialises in a suite of Application Development that is mission critical for business and enterprise, for clients across the world.

We are expanding rapidly and are working on several cutting technologies across various domains. We have some of the best in the industry working with us and are looking for young and bright minds to join us

  •   Product Engineering
  • Software Testing
  • Internet of Things

We are a team of specialists with experience in a gamut of technologies and domains.

We possess a deep understanding of different languages and tools in the areas of design, development, and testing. Certified and experienced, our team combines technical know-how with industry best practices to create sustainable solutions.

We deliver bespoke industry specific solutions leveraging our extensive digital experience, design-led engineering approach and agile processes backed by our strong expertise in cutting edge technologies


To nurture the technical prowess of these solution providers and strengthen our offerings further – Dew Solutions has institutionalised various Centres of Excellence (CoEs).

These Centres of Excellence drive the experience and excellence which we want to deliver to our customers. Our subject matter experts in these CoEs collaborate with our customers to co-create and co-innovate thereby empowering them with ‘real’ solutions which their business needs.

  • Development
  • How To Guides
  • UX & Design

What are Job Stories and How are They Different From User Stories?

how to write job stories

Job stories also referred to as a jobs-to-be-done framework are nothing but a more generalized and enhanced version of user stories that primarily focus on defining user tasks in a product design. They are considered to be a great alternative for user stories. Unlike user stories that are created based on personas, job stories involve creating a UX design keeping in mind the needs and concerns of the real users. It avoids the personas approach, in other words, personas become contexts.

User stories are merely assumptions or one’s own imagination. Moreover, they do not acknowledge causality. The challenge that arrives when you form a user story based on assumptions is that you fail to properly understand the actual problems of a real user, and therefore they remain unaddressed. Job stories, on the other hand, are based around real people, and not assumptions. Here, the user situation triggers a motivation that leads to the expected outcome. The concept revolves around “when” and most importantly “why” a user wants to perform a certain task instead of what they want to perform and how they want to perform. Put simply, we can say that Job stories are more concerned with motivation and outcomes rather than a user performing some function.

Job Stories Template

A job story UX template or format comprises three key elements-

1. “ When ” (the situation or the context)

2. “ I want to ” (the goal or motivation), and

3. “ So I can ” (expected outcome)

The first element provides the context to the story or the thing which is triggering the story in a particular situation. The second point which says “I want to” provides the motivation for the story whereas the last element “so I can” indicates the desired outcome.

For example, “When one of my contacts joins the messaging app, I want to be notified about it so I can start a conversation with him/her”

Job Stories vs User Stories: Understanding with an example

Let’s take an example to understand how Job Stories are more meaningful than User Stories. Consider a scenario where a person makes a payment at the time of checkout on an eCommerce website.

A user story related to it can be-

“As a user, I want to be shown a message telling me not to make the transaction twice so that I avoid making repeated payments.

A job story of the same scenario would be-

“When I checkout, I want to see a success message so I can avoid making the transaction again”

This clearly highlights the “when”, “I want to” and “so I can” points of the job story template.

Which do you think adds more meaning to the story? The second one, right? There are two main reasons behind this. First, the story applies to everyone doing a transaction on the site irrespective of who the user is. Second, it provides a clear context to when it is happening, i.e. post-checkout. If you carefully take a look at the user story, it never really tells us anything about the user and when the message should be displayed. When there isn’t a situation, it’s important to define the “user”.

Most of the part remains identical in a job story as well as a user story template. It’s just a matter of defining the context and the user.

When to Use What?

Both user stories and job stories have their own strengths in UX design. Deciding when to use what also depends on the product. For instance, user stories can be used for products whose users vary significantly, and it is imperative to thoroughly understand those users. This is the reason why user stories begin with “ As a [user] ” where we have to clarify who the user is. When we talk about user stories, who will be doing the story is as important as what they will be doing.

Conversely, in job stories, who is doing the story isn’t necessarily important, but the context is. You define a situation when a story will happen without thinking much about who is performing it. Job stories become a better option to opt for when your product has users but their needs do not differ a lot.

So the conclusion is that if your product’s users differ in substantial ways, user stories tend to be a great option but if they do not differ significantly, job stories are a better choice. The best thing to do, if possible, is to merge both and form a better contextual story with the users clearly defined.

Tips to Write Better Job Stories

A job story can be presented in a much better way if you follow the following tips-

1. Add More Context

Creating a situation is one thing, refining it is another which can be done when you add more context to it. By adding more contextual information to a situation, it will be easier for you to design a solution that eliminates the various concerns of real people. For example, a situation that says “When I want something to eat” can be further refined to “When I am in a hurry and want something to eat.” You can plan out the solutions accordingly.

2. Keep Your Focus Around “Real” People

Jobs stories, as we mentioned earlier, are based on real people, unlike User stories which are based on personas. The latter may create an incorrect image of the ideal customer and can leave holes in your design. Moreover, can you ask a persona why did they choose one product over the other? What challenges did they face while browsing your product or the competitor’s and what solutions did they demand? The answer is NO, you can’t.

With Job Stories, you fill this gap as it comes from the opinions of real people. You conduct interviews, talk to people and figure out the concerns they have and the contexts that were functional at the time when they used the product.

3. Supplement Motivation With Forces

Another way to write your job stories and make them better is by adding forces to motivation which is much like adding more context to a situation. When you augment the motivation stage of the job story template with forces, it becomes more specific and helpful. You will be able to form a solution that minimizes the forces that push customers away from a product and boosts forces that pull them towards it. Let’s understand this with an example.

“When I am placing an order and encounter a problem, I want to be assisted right away so I can complete my order successfully.”

The situation: “When I am placing an order and encounter a problem”

The motivation: “I want to be assisted right away”. Now let’s couple the motivation with some forces. The forces that drive this motivation to get assistance can be-

I feel irritated because I wanted to place a quick order

I feel anxious because of payment failure

The outcome: “so I can complete my order successfully”

By adding forces, you reassure that customers won’t have to wait for long to get assistance and can place the order quickly, and can be made feel safe regarding the payment issue.

This provides a better solution, doesn’t it?

The Bottom Line

A design concept that involves motivation to reach the desired outcome is a far better approach than designing for attributes. That’s the key difference between User Stories and Job Stories. The former gives more value to roles and attributes while the latter gives preference to situations and motivations. User stories based on personas provide a reference to the different types of users and what they do but they never completely reveal why people do something. Knowing motivation is important and Job stories do that job remarkably.

What do you make of Job stories? Do share your thoughts in the comments below.

Want to hire expert UI/UX designers? Get in touch with us. We hold over 11 years of experience in UI/UX design and have built scads of products that are equally usable, functional, and beautiful.

Related Articles

how to write job stories

Things to Focus on When Designing for Mobile

how to write job stories

What is UX Testing and Why You Should Invest in it?

how to write job stories

A Beginner’s Guide To User Journey Mapping

how to write job stories

Empowering your digital dreams through our cutting edge solutions - Connect with us now!

Discover dew, our expertise, gurugram, india (hq).

P301, 3rd Floor, JMD Megapolis, Sector-48, Gurugram – 122018 +91 (124) 421-2275

Pune, India

WeWork, Magarpatta Futura, Magarpatta Rd, Kirtane Baugh, Pune, Maharashtra – 411028

16192, Coastal Highway, Lewes, Delaware, 19958 +1 (302) 208-6888

how to write job stories

  • Top Jobs in Fort Worth, TX
  • Back to main
  • Top Jobs and Employment Agencies in Fresno, CA

how to write job stories

  • Posted in Career Best Practices

What’s Your Story?


In the world of work, the best jobs don’t always go to the most experienced. Or the most qualified. Or the hardest working.

Often, the best jobs go to candidates who have a great career story.

When it comes right down to it, finding a great job is really all about marketing yourself. And marketing is all about telling great stories!

So…what’s your story?

In a job interview, a career story helps you capture attention and position yourself as the best candidate for the role. Here’s how craft a compelling career story – and get hired:

Know what a career story is – and what it isn’t.

In simplest terms, a career story is a brief, chronological synopsis of who you are, what you do (better or differently than anyone else), and your essential attributes. It’s a narrative that summarizes the value you bring to the table, conveys your passion, and explains why an employer should be interested in you.

Follow a logical structure.

A cohesive story creates a sensible order for your audience. Make sure yours has a:

  • Beginning. Where have you been? Start your narrative by briefly reviewing how you became interested in your career and got started in your field.
  • Middle. Where are you now? Cover your prior roles, accomplishments and transitions up to this point. Stick to high-level information, and highlight major chapters and defining moments in your career.
  • End. Where do you want to go? Ideally, your narrative should “connect the dots” and frame the available role as the next logical step in your career path. Include details that describe what makes you uniquely qualified for the opportunity.

Add in anecdotes.

Short, relevant anecdotes convey your passion, provide real-world proof of your claims, and help you make a personal connection.

While it’s natural to want to present yourself in the best possible light, be careful not to exaggerate or embellish . You’ll only create unrealistic expectations and set yourself up for failure.

Don’t ramble.

Attention spans are short, so keep your career story brief (less than two minutes). Once you’ve written your career story outline, put it away for a few days. Review it with a fresh set of eyes, and then edit out redundancies and nonessential information.

Practice telling your story.

Boost your confidence and ensure your narrative hits the right note by telling your story to a trusted friend or relative. While you don’t need to have every detail memorized, your enthusiasm and passion will shine through best when you’ve prepared well for your interview.

Ready to write the next chapter in your career story?

PrideStaff can help you:

  • identify your strengths
  • evaluate your career options
  • build your personal brand
  • find assignments and direct-hire positions that align with your career goals

Search jobs near me or apply with PrideStaff today!

  • Advancing Your Career
  • Career Consultants
  • Career Planning
  • Setting a Career Plan for 2020
  • Writing Your Job Story

how to write job stories

User Stories in Agile - How To Write With Examples

User Stories in Agile - How To Write With Examples

User stories play a crucial role in Agile methodologies, serving as the smallest unit of work and expressing the end goals from the user's perspective. They bridge the gap between technical requirements and the needs of the end-users, making them an essential tool in product development.

This article will guide you through crafting compelling user stories, providing practical examples to inspire your Agile team. We'll explore steps to create user stories, from outlining acceptance criteria to investing in their development, ensuring that your product meets the needs of its users.

What are user stories?

User stories are a fundamental building block in Agile methodologies, providing a simple and straightforward way to describe a software feature from an end user's perspective. They focus on the value that the user will gain from the feature rather than getting bogged down in technical details.

A user story is typically expressed in a simple sentence, following the format: "As a [type of user], I want [an action] so that [a benefit/a value]." This helps to keep the focus on the user's needs and encourages the team to consider the functionality from the user's perspective.

The INVEST principle is a widely accepted set of criteria for writing good user stories:

  • Independent: It must be independent; it shouldn't rely on another story.
  • Negotiable: You can always rewrite and change user stories until they become part of an iteration.
  • Valuable: A user story must offer value to an end user.
  • Estimable: At any time, you must be able to evaluate the size of a user story.
  • Small: Don't make your user story big; otherwise, it will be impossible to plan, task, and prioritize.
  • Testable: The user story should offer the necessary information to make test development possible.

Purpose of User Stories

User stories serve multiple purposes in Agile development as a vital tool for ensuring that the end product aligns with the user's needs and expectations. The key purposes they serve are:

  • Communication and Understanding: User stories facilitate communication between the development team and stakeholders. They help to ensure everyone has a clear, shared understanding of what is to be achieved and why it matters.
  • Focus on User Value: By framing features in the context of user needs, user stories ensure that the project stays focused on delivering real value to the end user.
  • Simplicity: User stories are designed to be simple and concise, cutting through non-technical language to express what the user wants in plain language.
  • Prioritization and Planning: User stories can help prioritize features based on their value to the user. They also assist in planning by providing a clear view of what needs to be done.
  • Flexibility: User stories are flexible. They can be rewritten or split into smaller stories as needed, enabling the team to adapt to changes quickly.
  • Testability: With clear criteria defined, user stories provide an excellent basis for creating test cases. They help ensure the resulting feature works as intended and meets the user's needs.

Who Creates User Stories in Agile?

In Agile development, user stories are typically created by the product owner . He is responsible for understanding the needs of the end users, stakeholders, and the business and translating these into user stories that the development team can work on.

However, it's important to note that while the product owner is primarily responsible for creating user stories, this is often a collaborative effort. The development team, stakeholders, and sometimes even the users themselves can contribute to creating user stories.

Who Accepts User Stories in Agile?

The development team presents the completed work to the product owner during the sprint review. At this point, the product owner reviews the work against the defined acceptance criteria. The product owner accepts the user story workflow if the work meets these criteria. If it doesn't, the story may be moved back to the product backlog for further work in a future sprint.

How to Write User Stories?

Writing user stories is a key part of Agile development. Here are the steps you can follow to create effective user stories:

  • Understand Your User: Start by identifying and understanding your user. Create personas that represent different user types for your product or service.
  • Define What They Want to Do: List the tasks they want to accomplish with your product or service for each persona.
  • Write the User Story: Use the standard format: "As a [type of user], I want [an action] so that [a benefit/a reason]." This keeps the focus on the user role, their needs, and the value they get.
  • Define Acceptance Criteria: You must meet these conditions to complete the story. They offer clear guidance on what is expected from the feature and how it should behave.
  • Prioritize Your User Stories: Some stories have different importance. Prioritize them based on their value to the user and business and the feasibility of implementation.

A typical user story includes:

  • Title: A short, descriptive name for the story.
  • Description: The user story itself is written in the standard format.
  • Acceptance Criteria: Specific conditions must be met to complete the story.
  • Story Points: An estimate of the effort required to complete the story. This is typically determined using Planning Poker, where team members make estimates using cards with values representing complexity and effort.

User Story Structure

The recommended structure for writing user stories follows the Role-Feature-Reason format. This is a simple yet effective way to frame the functionality and value of a feature from a user's perspective.

This refers to the type of user who will use the feature. It could be a specific user persona or role within your user base.

This is the action or capability that the user wants to perform or have. It should be described in terms of what the user wants, not system functionality.

This is the benefit or value that the user will get from the feature. It explains why users want this feature and what they hope to achieve.

User Story Syntax

The syntax for writing a user story in Agile development typically follows the formula: "As a [type of user], I want [some goal] so that [some reason]." This structure helps to keep the focus on the user and their needs. Let's break down each part:

"As a [type of user]": This segment represents the person or role using the feature. It's important to specify this to clarify who the functionality is being built for. For example, "As an administrator..."

"I want [some goal]": This part expresses the user's action or what they want to achieve. It describes the feature from the user's perspective. For example, "...I want to be able to create new user accounts..."

"so that [some reason]": This final segment provides the context and justifies why the user needs this feature, i.e., the benefit they expect to gain from it. For example, " I can give new employees access to the system."

User Story Description

User story descriptions provide more context to the user story and help the development team understand the requirements better. They often include the following elements:

  • Title: A brief, concise summary of the user story.
  • Narrative: This is the user story itself, following the format: "As a [type of user], I want [some goal] so that [some reason]."
  • Acceptance Criteria: Detailed conditions must be met for the story to be considered complete. They act as a checklist that confirms the story's functionality.

Story Mapping

Story mapping is a technique that provides a visual representation of the user journey through a product based on user stories. It's a helpful tool for understanding the bigger picture, prioritizing work, and planning releases.

Here's how you can create a story map:

  • Identify User Tasks: List all the tasks a user would need to complete to achieve their goal with your product or service.
  • Arrange Tasks Into a User Journey: Place the tasks along a horizontal line in the order in which a user would complete them. This forms your backbone.
  • Break Down Tasks Into User Stories: Write any related user stories for each task and place them vertically under the relevant task. These are your branches.
  • Prioritize User Stories: Determine which stories are most critical to the user journey and move them to the top of their respective branches. These become your walking skeleton, representing the minimum viable product.

User Story Components

User stories in Agile are a way to capture the product's desired functionality from the end user's perspective. They typically consist of three main components:

  • The Card: This is the written user story, usually on a physical card or a digital equivalent. The card contains the basic narrative. This keeps the focus on what the user wants to achieve and why.
  • The Conversation: This component refers to the discussions about the user story. Conversations help clarify the requirements and ensure that everyone on the team understands the story. These conversations can also add additional notes or diagrams to the card.
  • Confirmation: The acceptance criteria determine when a user story is done. They define the specific requirements that must be met for the story to be considered complete.

Story Cards in Agile

Story cards (index cards) are a traditional and popular tool in Agile methodologies. Each card contains a single user story, making them easy to handle, arrange, and rearrange as needed.

Cards are typically physically on a board in the team's workspace, visually representing the product and current sprint backlog. They can be moved around to indicate progress, from 'To Do' to 'In Progress' to 'Done.'

The front of the card usually contains the user story and a unique identifier. At the same time, the back can be used for additional details, such as acceptance criteria, notes from conversations, and any other relevant information.

User Story Examples

Developer user stories.

As a software developer, I want an integrated development environment (IDE) that can detect syntax errors to write code more efficiently and with fewer errors.

User Story in Business Analysis

As a project manager, I want a tool that can track project progress and alert me when tasks are falling behind schedule so that I can proactively manage resources and timelines.

Website User Story

As a blog reader, I want to be able to leave comments on articles so that I can engage with the author and other readers.

How to write good user stories?

Write good user stories by focusing on best practices and how you can avoid common pitfalls.

User Story Best Practices:

  • User-Centric: User stories focus on the needs and goals of the end users, ensuring that the features being developed provide value and address their pain points.
  • Independent: Each user story is self-contained and independent of other stories, allowing for flexibility in prioritization and implementation.
  • Specific and Measurable: User stories are clear and specific, with well-defined acceptance criteria allowing easy evaluation and testing.
  • Small and Iterative: User stories are small enough to be completed within a single sprint or iteration, enabling faster feedback, iteration, and value delivery.
  • Collaborative: They encourage collaboration between stakeholders, product owners, and development teams, fostering shared understanding and collective decision-making.
  • Prioritized: User stories are prioritized based on business value, user impact, and project goals, enabling teams to focus on the most important features first.
  • Estimable: User stories are estimable, allowing the team to estimate the effort, complexity, and resources required for implementation, aiding in planning and prioritization.
  • Testable: They have clear acceptance criteria defining a successful outcome, facilitating effective testing and validation.
  • Valuable: Each user story delivers value to the end users or stakeholders, aligning with the overall vision and objectives of the project.
  • Emergent: User stories are open to refinement and adaptation as new insights, feedback, or changes in requirements emerge during the development process.

Common Pitfalls to Avoid in User Story Creation

  • Writing Too Detailed Stories Too Early: Details should be discovered closer to development.
  • Leaving Out the 'Why': The purpose behind the story (the 'so that' part) is crucial because it provides context and helps prioritize.
  • Not Involving the Team: The best user stories are written collaboratively, with input from the whole team

Types of User Stories

  • Functional User Stories: Describe features or functions that directly interact with users. E.g., "As a user, I want to save my shopping cart."
  • Non-Functional User Stories: Define system qualities like performance and security. E.g., "As a user, I want my data to be encrypted."
  • Technical or Infrastructure User Stories: Focus on system-level concerns, usually written by developers. E.g., "As a developer, I want to refactor the codebase."
  • Constraint User Stories: Outline restrictions or limitations. E.g., "The system must support 2000 concurrent users."
  • Business Rule User Stories: Describe rules that the system must conform to. E.g., "As a manager, I want to approve all refunds."
  • User Persona Stories: Based on specific user personas, focusing on their unique needs. E.g., "As a new user, I want a tutorial."
  • Epic User Stories: Large user stories that need to be broken down into smaller stories. E.g., "As a user, I want a personalized dashboard."
  • Spike User Stories: Used to research or create a proof of concept. E.g., "Research ways to integrate with the payment gateway."

What Is a User Story in Agile?

A user story in Agile is a tool that captures a software feature from an end-user perspective, focusing on the user's needs and the value they would get.

What Is a User Story in Scrum?

In Scrum , a user story is a functional increment of work used to break down the work into manageable chunks that deliver value to the user.

What is a Kanban User Story?

In Kanban , user stories help visualize the workflow. They represent individual pieces of work that move across the Kanban board as they progress.

Prioritizing and Managing User Stories

When it comes to prioritizing user stories in the product backlog, several techniques can be used.

  • Stack Ranking: This technique involves taking the list of items that need prioritization and ranking them from the most important to the least important. The items at the top of the stack are given the highest priority.
  • Kano Model: The Kano Model is a technique that helps prioritize user stories based on their impact on customer satisfaction. It categorizes user stories into different categories, such as basic expectations, performance factors, and delighters.
  • MoSCoW Method : MoSCoW stands for Must have, Should have, Could have, and Won't have. This technique involves categorizing user stories based on their importance and urgency. Must-have stories are given the highest priority, while won't-have stories are deprioritized.
  • Bucketing System: This technique involves organizing items on the backlog into buckets or categories based on their themes or priorities. This helps in better organization and decision-making when prioritizing user stories.

When it comes to tools you can use to manage user stories, ActiveCollab has shown amazing results. It manages stories by providing a user-friendly interface to create and prioritize them. It enables collaboration and communication among team members through comment sections.

Tasks can be assigned to team members with due dates for accountability. Progress tracking and reporting features help monitor project milestones and performance.

User Story Board

User storyboards are visual tools used to track the progress of user stories through different stages of development. They typically consist of columns representing the various stages, such as "To Do," "In Progress," and "Completed." User stories are cards that move across the columns as they progress.

By using user storyboards, teams can quickly assess the status of each story, identify bottlenecks, and prioritize work effectively. It provides a clear visual representation of the workflow, improves communication, and helps team members stay aligned throughout development.

Burn-down Chart and Burn-down Rate

A burn-down chart is a visual representation that tracks the progress of work completed against time during a project. It helps teams monitor and manage their progress toward completing the project's tasks or backlog items. The chart consists of two axes: the x-axis represents time, divided into iterations - the number of stories per sprint, while the y-axis represents the remaining work or effort.

As the team completes tasks, the chart's line or curve should gradually slope downwards, indicating the reduction in remaining work over time. By the end of the project, the chart should reach zero, indicating that all planned work has been completed.

On the other hand, the burn-down rate measures the pace at which work is being completed. It represents the rate at which the remaining work is decreasing over time. A steep slope indicates a fast rate, while a shallow slope suggests slower progress. By monitoring the burn-down rate, teams can assess if they are on track to complete the work within the desired timeframe or if adjustments need to be made to meet their goals.

Benefits of Using User Stories

  • Increased flexibility: User stories allow for adaptable planning and prioritization, enabling teams to respond to changing requirements effectively.
  • Improved product quality: User stories focus on end-user needs, leading to a better understanding and delivery of valuable features.
  • Enhanced customer satisfaction: By capturing user requirements and feedback, user stories help ensure the product meets customer expectations.
  • Better project control: User stories provide clear visibility into project progress, making tracking and managing tasks easier.
  • Faster ROI: Prioritizing user stories based on value allows teams to deliver high-impact features earlier, leading to faster return on investment.
  • Reduced risks: User stories promote incremental development, minimizing the risk of developing unnecessary or low-value features.
  • Higher team morale: User stories foster collaboration and empower teams, increasing motivation and productivity.

Challenges Associated with User Stories

  • Simplification of complex features: User stories need help to capture complex requirements' intricacies, leading to oversimplification.
  • Ambiguity, if not well-defined: Insufficiently detailed user stories can result in misunderstandings and confusion among team members.
  • Risk of scope creep: User stories can expand beyond the original project scope without proper control, causing delays and resource overruns.
  • Potential for neglecting technical tasks: User stories primarily focus on user needs, overlooking important technical considerations or infrastructure improvements.
  • Difficulties in scaling for larger projects: Managing and coordinating numerous user stories can become challenging as project size and complexity increase.
  • Reliance on continuous stakeholder involvement: User stories require ongoing collaboration with stakeholders, which can be challenging to maintain in certain situations.
  • Misinterpretation of user needs: Ambiguities or a lack of clarity within user stories can lead to misunderstandings and deviations from user expectations.
  • Overemphasis on short-term goals: User stories often prioritize immediate deliverables, which may hinder long-term planning or strategic decision-making.
  • The challenge in integrating with non-agile methods: Incorporating user stories into non-agile processes can pose integration challenges and require adaptation.
  • Inconsistency in story point estimations: Estimating story points accurately across different user stories can be challenging, leading to inconsistencies in work effort estimations.

User Story Breakdown

User story breakdown divides a user story into smaller, more manageable tasks or sub-stories. It involves decomposing the user story into specific, actionable steps that the development team can work on. The purpose of breaking down user stories is to ensure clarity, facilitate implementation, and enable better estimates and track progress.

During the breakdown process, the development team collaborates to identify the individual tasks or sub-stories required to fulfill the user story's objectives. These tasks should be small enough to be completed within a single Iterative refinement or sprint. They should also be well-defined, independent, and testable.

By breaking down user stories, teams can:

  • Gain a deeper understanding of the work involved: Breaking down user stories helps uncover hidden complexities and dependencies, allowing for more accurate estimation and planning.
  • Facilitate collaboration and delegation: Smaller tasks are easier to assign to individual team members, promoting parallel work and reducing bottlenecks.
  • Improve estimation and tracking: Breaking down user stories allows for more granular estimation and better progress tracking, as each task can be individually estimated and completed.
  • Enhance flexibility and adaptability: Smaller tasks enable teams to respond to changes and adjust priorities more effectively during development.
  • Enhance transparency and communication: Breaking down user stories promotes clear communication between the development team and stakeholders, as the breakdown provides a detailed view of the work being done.

how to write job stories

Fundamentals of Agile Project Management

All Newsletter subscribers can download this (and other) ActiveCollab Project Management Guides.

*Enter your email address and subscribe to our newsletter to get your hands on this, as well as many other free project management guides.

Sorry, we could not subscribe you at this moment. please double check your email address. If issue still persist, please let us know by sending an email to [email protected]

Make Real Work Happen!

Start your trial today, free for 14 days! Onboard your team, plan, collaborate, organize your work, and get paid.

By signing up you are agreeing to the ActiveCollab Terms of Service & Privacy Policy .

Great, just a few seconds and you're in.

We detected that you already have an ActiveCollab account

You can log in to existing account or you may start a new one

Great, your account has been created!

You will be redirected to your new account in a couple of seconds.

Sorry, we could not create an account for you at this moment.

Please double check your email address. If the issue still persists, please let us know by sending an email to [email protected]

Sign up for ActiveCollab newsletter!

Choose your favorite topics and we'll send our stories from the tech front lines straight to your inbox.

Unsubscribe at any time * Privacy Policy

Just a second

Thank you for subscribing to our newsletter.

Oops, something went wrong! Please try again later.

Related Articles

Agile Project Management

Agile Project Management

Advantages and Disadvantages of Agile Project Management [Checklist]

Advantages and Disadvantages of Agile Project Management [Checklist]

Start your free trial.

Enter your email to get 14 days of ActiveCollab absolutely free, without any limitations.

Mark as disposable account.

ActiveCollab Is Using Cookies

By accepting all cookies you are giving us permission to use our tracking technologies to personalize your content and provide you the best possible experience on our website. Essential cookies are always on as we need them to make sure our website is working properly.

Read more about our cookie policy.



How to Write a Good User Story: with Examples & Templates

Published: July 20, 2018

12 min read

Last updated: May 2, 2022

Andrii Bondarenko

Andrii Bondarenko

Content Team Lead @ Stormotion

In this article, you'll learn:

🤔 What is a User Story?

👍 what are the benefits of creating user stories, 📝 how to write user stories: our workflow, 💡 conclusion.

When you start to dive into Agile, the first thing you notice is how user-centered this approach is. It shifts the focus from just coding and designing to delivering real value to your end users, stakeholders and business in general.

Agile User Stories are an essential component of this ideology that lets you define what benefits your product will bring to your target audience (and, eventually, how it will boost your KPIs and other metrics).

User Stories help to constantly improve the value of your product to the end users

User Stories help to constantly improve the value of your product to the end users ( image by Aleksandar Savic )

We at Stormotion love Stories. As an Agile-driven Team we actively use them to get a better understanding of what benefits our clients’ products deliver to their end users. They also drive collaboration and creativity, pushing us to non-trivial development solutions.

So today we’re going to share our knowledge and experience on this matter to help you improve your Story-writing skills. Enjoy!

User Stories are one of the core elements of the Agile methodology. However, they’re often jumbled with software requirements which isn’t true. So what is a User Story?

User Story is a small (actually, the smallest) piece of work that represents some value to an end user and can be delivered during a sprint.

In projects like mental health app development , the main aim is to put end users at the center of the conversation, capturing product functionality from their perspective. Thus, developers get a better understanding of what, for whom and why they’re building.

User Stories help understand what value a product provides to its end users

User Stories help understand what value a product provides to its end users ( image by Duo )

Great User Stories always fit the INVEST set of criteria by Bill Wake:

  • I ndependent – they can be developed in any sequence and changes to one User Story don’t affect the others.
  • N egotiable – it’s up for the team to decide how to implement them; there is no rigidly fixed workflow.
  • V aluable – each User Story delivers a detached unit of value to end users.
  • E stimable – it’s quite easy to guess how much time the development of a User Story will take.
  • S mall – it should go through the whole cycle (designing, coding, testing) during one sprint.
  • T estable – there should be clear acceptance criteria to check whether a User Story is implemented appropriately.

The User Story format (which is used by the Stormotion team as well) is quite plain and short:

As a [type of user], I want [an action] so that [a benefit/a value]

Looks like nothing difficult, huh? Here are a few User Stories examples that fit some made-up taxi app project:

  • As a driver , I want to block badly behaved passengers so they are never shown me again .
  • As a passenger , I want to link the credit card to my profile so that I can pay for a ride faster, easier and without cash .
  • As a driver , I want to add photos of my car in my profile so that I can attract more users .
  • As a passenger , I want several available drivers to be displayed so that I can choose the most suitable option for me .

Sounds quite easy but User Story development isn’t often that simple. Yet, later on, we’ll share some of our proven tips that will help you make only good shots.

A few more examples of User Stories for websites (*image by [Philipp Kühn]({ rel="nofollow" .default-md}*)

A few more examples of User Stories for websites ( image by Philipp Kühn )

Is there something else?

Despite we’ve just figured out that Agile User Stories are independent and should be understood as totally separate units of work, sometimes they’re grouped together. So when working with them you are likely to meet and use the concept of an Epic . What is it?

An Epic is a high-level body of work that bands together with a group of related Stories.

We at Stormotion use Epics to describe more complex tasks and create a clear hierarchy that allows managing development more easily and delivering new value to the users while working towards a bigger goal. Yet, the User Story format itself stays the same.

The hierarchy of Epics and Stories

The hierarchy of Epics and Stories ( image by Atlassian )

Let’s learn how they compare to the User Story format:

Imagine that you’re building a dating app. In this case, good Epic and User Story examples (but don’t take them too seriously) will be:

So, Epics provide us with a high-level view of our goals and how we’re moving towards them. It also helps us during the prioritization process since we can check which Epics require our attention the most and, therefore, which Stories should be implemented first.

How to Prioritize the Feature Development

Oh, one more thing!

Don’t forget to add an acceptance criteria .

An acceptance criteria is a set of conditions that are used to confirm when a Story is completed.

Every Story should have clear acceptance criteria

Every Story should have clear acceptance criteria ( image by Hai Peng )

Also, these conditions provide us with a deeper and better understanding since they include key info on how Stories perform. Let’s reuse one of the User Story examples from the beginning of the article:

As a passenger, I want several available drivers to be displayed so that I can choose the most suitable option for me.

What acceptance criteria can be applied to this Story?

  • The app shows drivers that were online within last 20 minutes and don’t have an ongoing ride.
  • The app shows only 5 drivers that are closest to the user.
  • A user can browse profiles of these drivers, including their photos and rates.

As you can see, now we not only know the value of this Story to users but also understand some key characteristics that require special attention during implementation.

However, you're free to choose how detailed your acceptance criteria will be. It can range from "just let it work in any convenient way" to even more detailed sets of conditions than in the example above.

That's greatly depends on your development team so there's no "correct answer". If your team needs guidance and clear, with-no-room-for-interpretation tasks you'd better stick with detailed instructions on how stories should perform. Otherwise, the "just get it done" approach may work as well.

How to Evaluate Your Startup Idea

Wow, it’s been said a lot about User Stories. But why are they so important to Agile teams?

If you were ever involved in working with Agile frameworks, you already know that both Scrum and Kanban teams greatly benefit from writing User Stories.

User Stories provide benefits for all kinds of Agile Teams

User Stories provide benefits for all kinds of Agile Teams ( image by Andrew McKay )

In Kanban, teams accumulate Stories in a Backlog and then run them one by one to support the work-in-progress flow. This helps to constantly stay on track and improve development team KPIs.

Scrum (which we usually prefer at Stormotion) teams also love User Stories. We actively use them to make estimations, prioritize and plan sprints which helps us stay agile and flexible to any changes. This is especially beneficial when we’re working with Startups that are at the MVP-Stage and have limited resources before pitching their project to Angel Investors.

Stories are actively used by Kanban teams as well

Stories are actively used by Kanban teams as well ( image by Tahir Yousaf )

Except for the above-mentioned, there are some vivid benefits that are common to all Agile teams:

  • Keep you focused on the business value. It helps to make your app not only well-built from the technical perspective but also useful to the end users.
  • Enable creativity. Since it contains a minimal amount of info, your team is free to drive creative ideas to find the best solution to implement a Story.
  • Your project becomes more manageable. We at Stormotion know that it’s a way easier to work with small and estimable Agile User Stories rather than with big complex tasks.
  • They inspire the team! Every developer loves this sweet feeling of a small win which motivates him to work even harder.

Now let’s dive into the process of creating a User Story!

Project Discovery: What's and Why's?

We’re getting to the most thrilling part of our article. However, before we share our step-by-step instruction on writing a User Story, it’s crucial to figure out 2 essential questions: who and when makes them.

Who is responsible for creating a User Story?

As a rule of thumb, Stories are mainly written by Product Owners since it’s their responsibility to keep the Backlog filled with tasks. Yet, don’t forget that Agile is based on communications and opinions exchange between experts. So...

It doesn’t necessarily mean that they should be written only by a Product Owner. The more people join the conversation, the better.

At Stormotion, Stories are written by all team members who are related to the business-side of the project (sales managers, marketers, a product owner etc.), since it let us look at the future app from the perspective of any potential kind of user. The responsibility of the Product Owner in this case is to confirm that they’re match the INVEST criteria.

Stories are created through collaboration

Stories are created through collaboration ( image by Dmitrii Kharchenko )

When are User Stories created?

A Story-writing meeting in our HQ is usually held near the start of the project . We prefer to gear ourselves up to make sure that a project goes well from the first day to the last.

Later on, we’re able to use our Scrum User Story list to prepare more detailed estimates (for example, by the end of the Discovery Stage), prioritize feature development for sprints and so on.

How to Estimate Software Development Time Accurately?

Also, we supplement the original list as we work on a project with new stories to stay up-to-date with our client’s requirements.

What are the steps to write great Agile User Stories?

First, let us remind you of a common User Stories template:

Seems short and easy to write. By the way, you're welcome to create your own User Story template. However, we at Stormotion have a specific workflow that helps us deliver the best Stories:

  • Make up the list of your end users. Define what their “pain” or “need” is, which you’re trying to solve.
  • Define what actions they may want to take.
  • Find out what value this will bring to users and, eventually, to your product. Also ask yourself - will any party pay us for this?
  • Discuss acceptance criteria and an optimal implementation strategy.

Let’s look them over now!

Step 1: Think of the “Who”

This is the first and, maybe, the most fundamental step. Before writing a User Story you should actually know who the end users of your product are. And more important - what needs they have, which you are trying to cover.

During our Story-writing workshops, we try to omit using such a role as simply “the user”. It can be applied to any person - from your customers to admins - and, therefore, it doesn’t reflect the personality of particular target groups, the way they interact with the application.

It's important to correctly define your user persona ( image by Grzegorz Oksiuta )

If you want to achieve really great results you may want to dive into your audience even more. Instead of just naming users after their role (for example, “a driver”) try to create some kind of a buyer persona.

Here are a few more tips from our own experience:

  • It’s all about the user. Not about developers. And even not about a Product Owner. Each Story should be valuable to some group of your end users.
  • Don’t think of users only as external customers. It’s true that your Stories will be mostly about them. But it’s also true that you have to consider internal users such as admins, editors etc.
  • Feel some empathy. Give your “user” a name. Think of his mobile habits, what issue your app is going to get resolved for him and how you’re going to make this path easier and faster. Remember some people who you know from the real life and who fit this portrait; feel how you relate to this target group.

Step 2: Think of the “What”

Now we have a few groups of end users. The next step we do is define what functionality each user expects, how he’s going to interact with the app.

Then you should find out how users are going to interact with your product

Then you should find out how users are going to interact with your product ( image by Johny vino™ )

These are the main rules to remember when writing an action for a Kanban or Scrum User Story:

  • One action per a Story. If you want to write something like “as a customer I want to browse items and add them to the cart” you’d better split it into 2 separate Stories.
  • Describe an intention, not a feature. For example, instead of “I want to manage my profile” create a few Stories like “I want to be able to register”, “I want to upload my profile photo”, “I want to link my credit card to my profile” - each Story will have a different value.
  • Keep it short. Users don’t care what library you will use to let them browse the list of items so leave all the tech details aside.
  • Avoid describing UI. We’ve defined Stories as negotiable, remember? That's why all good User Story examples don't include any UI details. So don’t try to compose any special way to implement them (we’ll do this later).

Step 3: Think of the “Why”

Finally, the last piece of our User Stories template is dedicated to a value that users get after performing an action. It may seem like not a big deal but it’s often the most tricky part of User Story development.

Pay attention to how users interact with your application

Pay attention to how users interact with your application ( image by Andrew McKay )

However, your [so that] section should always correspond with your metrics and KPIs. It should either improve the UX, increase retention rates, shorten users’ journey to the issue solution or whatever. Each Story should contribute something to the general goal of your product .

If you can’t answer what value this feature brings to end users and your product as well, then you’re doing something wrong.

For instance, there are a few User Stories examples with a well-written value for our ongoing food ordering app project:

  • As a customer, I want to get notifications when there are new hot offers so that I never miss the best deals. [how it affects KPIs: users get notified ➡️ they use the app more often ➡️ retention rate grows].
  • As a restaurant manager, I want to complement dish description in the menu with a photo so that it looks more attractive to the customers. [how it affects metrics: users are satisfied that they can see photos ➡️ sales grow ➡️ your revenue also grows].

Step 4: Discuss a Story

Finally, we always discuss User Stories after they’ve been created. Even if it seems like nothing to talk about.

Don't underestimate the importance of the brainstorming session

Don't underestimate the importance of the brainstorming session ( image by Monika Pola )

During this Q&A session, we ask the author of the Story to provide more details or clarify something if needed. It helps us understand how it should work and agree on acceptance criteria. This way we review all mobile app user stories examples one by one.

Then we hold a brainstorming session with the whole team working on the project. It allows us to find out the best ways to implement User Stories from the tech perspective.

How to Select an Agency for Your App Development?

So that’s how to write User Stories in a nutshell. Our Stormotion Squad also uses the following tips when working on this task:

  • Start with Epics. It’s usually easier to move from more complex tasks to more specific ones so try writing Epics and then split them into Stories.
  • Listen to feedback. Sometimes you don’t need to guess Stories - ask your real end users for feedback and use their ideas as a source of inspiration.
  • Don’t introduce details too early. It’s better to hold the brainstorming session before each sprint to discuss how to implement planned Stories.

User Stories are an essential element of the Agile approach that can bring many benefits to your project. However, it’s important to write them correctly which requires some time and skills.

Examples of good User Stories meet the INVEST criteria, meaning that they’re:

  • I ndependent
  • N egotiable

The common User Stories template includes the user, the action and the value (or the benefit) and typically looks like this:

As a [type of user], I want [an action] so that [a reason/a value]

User Stories can help you to constantly improve the value of your product, estimate development efforts in an appropriate way and prioritize feature development during the MVP and post-MVP stages.

Boost Your App Development With Us!

Was it helpful?

About author

Content-Marketing Maestro @ Stormotion. Crafting compelling stories for a brighter world.

Andrii Bo...

Author page

Stormotion's ChatGPT Journey

Stormotion's ChatGPT Journey


how to write job stories

Top 5 Best Practices for Integrating ChatGPT in Your App



Looking to build a music streaming platform like Spotify? This article provides a step-by-step guide on how to develop a successful SaaS app, covering everything from app development to user experience.

How to Build SaaS App Like Spotify

How can we help you?

Please tell us about your project

By sending this form I confirm that I have read and accept the Privacy Policy

Our clients say

Stormotion client Pietro Saccomani, Founder from [object Object]

They make the whole business work for us, and their improvements are fundamental to our operations. They’re reliable, honest, and willing to try new things that will help us. We appreciate how flexible and easygoing they are.

Pietro Saccomani, Founder

Thea Kelley Career Services logo

  • Job Interview Coaching
  • Job Search Coaching
  • Resumes and LinkedIn

Download Our Free Report

Get my concise, FREE report for step-by-step guidance to STAND OUT & WIN in interviews!

Job Search Tool #1: SOAR Stories List

by THEA kelley |  March 15, 2018

About Resumes, Profiles, Bios & Letters , Career Management , Getting Interviews - Search Strategy , Getting Offers - Interviewing

how to write job stories

You won’t show this to employers, but you’ll use it as source material for interviews, your resume and other materials.

In a previous post I wrote about one of the most powerful interview storytelling techniques, the SOAR technique (including the Situation, Obstacles, Actions and Results), offered examples, and promised some additional tips on how to use SOAR stories. Here are those tips.

SOAR stories are more or less the same as STAR stories . The tips below apply equally to both models.

Keep a SOAR stories list – forever!

  • First, come up with maybe 20 good stories. See my post  “How to Identify Your Accomplishments”   for tips.
  • Keep a written list in your computer, not just in your head or on paper. You’ll need to be able to add to it, edit it, and find it easily, even after this job search. Keep it forever.
  • Give each story a unique title, e.g., “PeopleSoft Implementation at Bigg Co.” or “Team-Building after TechSys Merger.” This helps you remember them.
  • Do NOT write the stories word-for-word. (This makes the list long and unwieldy, and may cause you to recite the stories in  a stilted, unnatural way at your interviews. Very unconvincing!) Instead, just note the key points in outline form, avoiding full sentences. If you feel you absolutely must write out your stories in full, do that only as an intermediate step. Then immediately turn the full story into an outline and practice telling the story from that.

Identify the Skills and Strengths.

Under each SOAR story in your list, jot down the Skills and Strengths you demonstrated in achieving the result.

For example, if you identified the need for a new software in your office, sold the idea to management, then selected and installed the program, you may have used the following skills and strengths: initiative, research skills, presentation and persuasion skills (to convince management), technical skills, training skills, team leadership, change management, cross-functional collaboration, attention to detail and analytical skills.

While you won’t mention this list of skills and strengths in telling the story, it’s useful for your own reference. This way, when an interviewer asks you to tell about “a time when you collaborated cross-functionally to achieve a goal,” or “a time when you took the initiative,” you’ll know you have a story to illustrate that.

Study and practice with your list.

Practice talking through the stories – by yourself, with friends, and maybe with an interview coach.

Study and prepare as you would for an oral exam where a high grade could make you thousands of dollars. Because that’s exactly the case!

Be ready for behavioral interviews.

A behavioral interview question, typically starting out with “Tell me about a time when,” requires you to tell a story from your experience. Many interviewers focus heavily on behavioral questions. If the interview is long, or if there are several interviews, you may need many stories!

Tell a story even when it’s not required.

Maybe your interviewer has never heard of behavioral interviewing and just asks general questions like “What’s your management style?” Instead of just saying you focus on motivating each individual, include a story that illustrates that style – and how it has led to great results. Hint: It’s easiest to fit stories into your answers if you practice both long (30-60 seconds) and short (10-30 seconds) versions.

Prove your key points.

What are your key selling points, the most crucial reasons why you’re the best person for the job?

Let’s say your top three are your people skills, your analytical abilities and your 10 years of experience. It’s easier to prove the 10 years of experience, but how can you prove the other two? By giving examples – also known as SOAR stories.

Claiming you have a certain talent isn’t enough. A story is worth a thousand claims.

Make networking conversations memorable.

Interviews aren’t the only time for telling a story. You need everyone you meet in your job search to be left with a strong impression of your abilities. To avoid sounding “full of yourself,” be concise – which takes practice! – and listen more than you talk. Your networking partner probably has stories of their own.

Create compelling written materials.

As you develop your list of stories, you’ll probably discover great new material to improve your LinkedIn profile, resume, cover letters and other marketing tools. Of course, for these purposes you’ll need to boil them down to short bullet points.

Your success stories list is there behind the scenes, the unsung hero of your job search. It is a crucial, must-have tool, so give it a high priority.

Keep your SOAR stories concise.

Like any interview answer, a SOAR story should be about a minute long. Make a long story short.

Once you land your new job, don’t lose track of your SOAR stories list. You’ll probably need it again! This post was originally published in March 2013 and has been updated.


How to Interview with Potential Direct Reports

How not to go blank in an interview, how to avoid toxic workplaces in your job search.

Leave a Reply

Your email address will not be published. Required fields are marked *

how to write job stories

You are using an outdated browser. Please upgrade your browser or activate Google Chrome Frame to improve your experience.

How to Write Better Construction Job Stories

The time-tested construction job story is among the most powerful marketing tools, especially in a world where well-informed customers prefer a demonstration of your product or service in action over a hollow sales pitch. The problem with job stories is that many are boring, and therefore, ineffective. It’s time to start engaging your audience and stop wasting your time and money.

Technical People Like Good Stories Too

There’s a narrative that some within our industry, namely engineers, prefer dry, fact-based writing. I’m calling B.S.

While it’s true that engineers like technical writing with measurements and quantities, it’s also true that as humans we are all hard wired to enjoy effective storytelling regardless of which side of the brain drives us.

After all, the cavemen weren’t gathered around the campfire discussing the results of the latest soil sample.

I once sent a construction job story to a national magazine and the editor suggested that some of the content was too artistic. Most of the readers were engineers and preferred technical writing, she said. This is a good time to remind you that you should always be aware of and respect the needs of the magazine and editor before, during, and after submitting a job story.

Most of the story, in fact, was technical. A small portion was artistic. This balance was intentional because one of the unique differentiators at Fraley Construction Marketing is the ability to weave effective storytelling together with technical writing.

The following is the artistic language in question to give you a better feel for what we’re talking about here:

The sheer power of the RG 21 T pile driver can be felt as steel vibrates against steel high above. Sand particles rain down lightly and the beach flexes as the 45-foot-long steel pile seems to slide into sand with the ease of a candle pushed into a birthday cake.

What if I had written it like this?

The RG 21 T pile driver drove 45-foot-long steel piles into the sand.

Boring, right? It’s certainly more succinct, and one of the rules of effective writing is to avoid using extraneous words. With that said, there’s nothing you can say to convince me that the reader will find this version more interesting. The original passage was intended to engage the reader by making them feel as if they were on the jobsite with me. Mission accomplished.

Tap Into Your Inner John Steinbeck

Do you recognize this passage? (Hint: it was required reading for many of us in grade school).

The tractors came over the roads and into the fields, great crawlers moving like insects, having the incredible strength of insects. They crawled over the ground, laying the track and rolling on it and picking it up. Diesel tractors, puttering while they stood idle; they thundered when they moved, and then settled down into a droning roar. Snub-nosed monsters, raising the dust and sticking their snouts to it, straight down the country, across the country, through fences, through dooryards, in and out of gullies in straight lines. They did not run on the ground, but on their own roadbeds. They ignored hills and gulches, water courses, fences, houses.

You’re correct if you identified it as a passage from the classic novel “Grapes of Wrath” by John Steinbeck. This book is full of incredible prose. This resonated with me because of the way he so descriptively captures heavy equipment at work. Admittedly you’re probably not going to write like Steinbeck, but wouldn’t your job stories be better received if you could tap into some of this writing magic?

Job Stories are Not Fiction

Let me state the obvious. Fiction writing and non-fiction writing are different. While heavy construction firms don’t need to mimic fiction writing, they should incorporate some of the creative writing techniques.

Don’t just tell us that your crane hoisted a 20,000-pound bridge beam. Describe it for us in detail. What sounds did you hear? Was the engine roaring? Were the backup alarms ringing in unison like slot machines at a busy casino?

What sights did you see? Did a plane fly overhead from a nearby airport? Was a crew of workers nearby pouring a concrete floor? Was the jobsite so thick with mud that the crane’s outriggers had to sit on wooden cribbing?

We could keep going but you get the idea.

“Engage the reader by making them feel like part of the action.

Use these passages sparingly throughout the story, but don’t get carried away or you may come off like an aspiring fiction writer.

Effective Storytelling is the Differentiator

Effective storytelling is the differentiator in the heavy construction market where the competition is tight and your audience’s time is limited.

The person you’re trying to reach may not have the luxury of sitting in front of a computer and reading articles during the work day. They may be working in the field for 12 hours.

Upon returning home, he or she might decide to read, but there are so many options. Check Facebook? Read a trade magazine? Return emails? One thing is certain. They won’t waste valuable time reading a job story unless it’s well written. Put these tips into play and your job stories will stand a much better chance of getting read.

What other techniques have you found effective for writing interesting job stories?

Sometimes it’s easier to just hire an expert than to follow advice. Click here to learn more about our job story services.

User Stories vs JTBD - Which One Should You Use and When?

What are jobs to be done (jtbd), which one is best, in conclusion.

Why did you come looking for this information today?

Regardless of the reason, let’s go through a bit of a review around User Stories and JTBD stories , provide some advice on how to use and improve them. Then we can compare them and give some advice on which (if any) is the best to use in your situation.

All You Need To Know About Product Management

CTA eBook image background

.css-uphcpb{position:absolute;left:0;top:-87px;} What are user stories

A user story represents a piece of work that, once released, adds value to the user , as they use your product or service.

This piece of work, or story, should be split in a way that can be delivered independently and without a special sequence. The decision on how to write the user story should be defined and agreed with the team who will be designing, developing and delivering the story .

A story, will include other items, such as an introduction, some acceptance criteria, or even, scope. It all depends on the practices adopted by your team, or organization.

User story template

The user story template will look something like this:

User stories x JTBD

The idea of having a template is so that you can easily and quickly share information about the main purpose of that piece of work. However, in environments where you have a standard ticket that everyone copies from (and you have 13 other tickets to write in a day) it is very tempting to write something like this:

“ As a user, I would like to be able to click the button, s o that I can see my balance”

Now, we’ve all done this, but this isn’t ideal, is it?

Writing a bucket load of stories that look like this won’t add much value to yourself, or the people who will work on the story (no, putting it on a table doesn’t make it any better).

The information in this user story will quickly become redundan t and repetitive (especially if you’re using something like Behavior-Driven Development - BDD, for example).

It doesn’t give context on why it is important and how it’s going to add value to the user; - what is marketing or sales teams meant to do with this information, for example?

It isn’t clear if this story is able to add value if released independently, nor if it has other dependencies.

How to improve a user story

If you’re going through the effort of writing a user story, here are some suggestions on how your user story could be improved:

“As a "user"

Replace “user” with the persona this story is about; or add some context about the person this story is for: “person who is responsible for x”; “person who cares about y”.

I would like to be "able to click the button"

I don’t know that many people who go around saying “ I would like to click this button, please”. This is your opportunity to illustrate the person’s end goal , which in this case could be “seeing my balance”.

So that I can "open the payment page" ”

Why does it matter for your user? What is it that you will be enabling? In this case, why does the person want to see their balance? For example,  “So that I can make sure I’m able to afford to spend money”.

Once you lay down information like this, it might actually spark some surprising conversations .

In this case, the user need is “ to be able to see if I have enough money ”. Maybe you are a conversation away of finding out that there is a better way to achieve this, or you can go deeper and really understand why this person is worried about not having enough money; who knows?

Well, you should… This is where the next method comes in: JTBD stories.

If you’re not familiar with the background of Jobs To Be Done: what it is and how to put it into practice; you can have a look at the previous article on it for some background.

In short, JTBD focuses on the user, what they are trying to achieve, and the value it will bring to them once they’ve achieved it . It is solution agnostic , as this method defends that our needs and ambitions have always been the same, it’s the context that is ever-evolving.

The lack of a clear solution can be mind boggling for a lot of people, so JTBD can be easily discarded. At the same time, it allows for exploration and that’s how competitive advantage can be created.

Jobs to be done story template

JTBD stories are one of the many outputs the jobs to be done framework, so bear in mind that when you write a JTBD story, your statement should have been validated.

JTBD and user stories

Seeing this in practice with our previous example, it would look something like this:

“ When it’s close to payday and I’m out of the house while I’m looking for something to eat for lunch, I want to see how much money I have left in my current account, so I can decide where I can go without breaking the bank ” .

How to write a good JTBD story

1. Give as much color and detail when framing the situation - this can be crucial when framing the solution piece.

For example, we can see this person is on the go, so our solution is mobile and might have to cater for poor internet connection, while being fast to load ( no one likes standing in the middle of the street looking at their phones waiting for something to load ).

On the other hand, you can see how this would look very differently if our person was an elder who were checking their balance to see how much money they could lend to their children.

2. Frame the “needs” part as a measurable outcome, so you can test if your solutions helped this person in achieving their needs (or not).

For example, this person might be oblivious to the fact that they will have a direct debit coming up, which will affect their balance, so by simply showing them their current balance we might be providing an incorrect reading of reality - considering they don’t want to “break the bank”.

3. Speak with the people you are creating the products for - this exercise becomes a lot easier and more useful when you have already spoken with actual people, so don’t skip that part, otherwise you are likely to be creating “fantasy stories”.

Jobs do be done hypothesis

While the JTBD story might be useful when having discussions with the team about a potential solution, if you’re already in a “go” mindset and the team is really solution focused, you can also explore the JTBD hypothesis template.

User stories give us the false sense of security that we always have the solution to the problem; the job is done when you release the story. With JTBD hat on, we know the solution can be anything, so there is an opportunity to explore and validate that solution.

Jobs to be done hypothesis and explanation template

WORD OF CAUTION : this template implies that you have already validated who the type of customer is, their problem, and the job to be done.

This hypothesis template might look like a good starting point for you and your team, but you might have false positives (or negatives) in your testing results if you don’t actually do some level of validation.

Jobs to be done vs User stories

We promised a comparison table, so here is a high-level summary of how User Stories and JTBD Stories differ from each other:

Jobs to be done vs User stories

User stories vs Jobs to be done comparison table

The idea of this article is to give you a good overview of both methods .

Find out which template works best for you and your team, but also which might result in a better system for the organization.

Don’t forget to consider which will support a better solution to the customer as well; - at the end of the day what really matters, right?

What to consider when thinking about a template, or framework?

There isn’t much to gain in starting “framework wars” of any kind; however here are some things you will need to consider for both:

1. Templates can be helpful, if/when everyone in that current team has contributed to the template and everyone understands why each section is there.

This is a good topic to discuss in retros, or when new team members join in.

2. When you find yourself in “copy-paste” mode, you might want to chat with the team about where your efforts are best placed . You might want to focus your thinking, or discussions around:

Have you been focusing on user outcomes and the value each piece of work is bringing?

Are you aligned on the definitions you are using (task vs story, for example)?

Who should be involved at what stage, or are the right people responsible for the right piece of work present?

3. No template is going to fix the fact that sometimes everyone is just too busy to discuss the next piece of work . If this is the case, it is likely that you will end up with more documentation than what is needed, with items that will never be released, and with poor quality products.

You can discuss this situation with your manager and clearly state: what is the problem, and what impact it will cause . Try working together on how to mitigate some of the things that are causing this to happen.

4. Remember that nothing’s “alive” until it is in the hands of the user.

What you expect the user will say, or think, it isn’t what they are going to say or think. Make sure that you (or someone in your team) is chatting with them and taking their feedback on board .

It is important to know and learn about the different frameworks we have available as product people, so they can support our job. Our job shouldn’t be made more difficult because of the frameworks we adopted.

We can use and adapt the best framework for the job and avoid getting lost in semantics which will create divides. Feel free to mix it all up, if that’s what makes sense to you and your team (and you are doing a good job with stakeholder alignment and shipping great stuff).

The role of any product person is to find the best way the organization can serve their customers , in a sustainable manner. This is a big enough job, so focus on that and the activities that will support your quest.

Inês Liberato

Inês Liberato

Andrea Saez

Andrea Saez

Vishal Chaudhary

Vishal Chaudhary

21 Sep 2023


Experience the new way of doing product management

Book a demo

Instant tour

airfocus modular platform

A former Amazon recruiter says one of the biggest mistakes job seekers make is putting Miss America-style statements in résumés

  • An ex-Amazon recruiter says a key mistake job candidates make is writing vague statements in résumés.
  • She compares these to "Miss America answers" that don't highlight specific achievements.
  • It's best to quantify your achievements, she said. 

Insider Today

A former Amazon recruiter says there’s one mistake that she keeps seeing both junior and senior employees making in their résumés: writing vague statements.

Lindsay Mustain — a former Comcast and Amazon recruiter and now CEO of Talent Paradigm — compared these statements to what she’d imagine hearing at a Miss America pageant in a recent interview with CNBC Make It .

It’s a simple response describing what you do in your role without highlighting your accomplishments, she said — using: "I had stakeholder meetings with people," as an example.

Mustain says those types of answers make a résumé look "like a glorified job description," adding that it’s not just junior employees but C-suite execs who are also guilty of this. 

Instead, she suggests quantifying your accomplishments, so you have numbers to back up how you helped a company move forward. 

The "more metrics and analytics you can add to your résumé, the more impressive," she said.

Recruiters often deal with tens of thousands of applicants, so a results-based résumé is more effective as the reviewers quickly get a sense of how much value you added to a role, she said.

Eugene Hayden, who has worked at companies like Google, KPMG, and the Boston Consulting Group, previously reviewed over 800 résumés to help people in his network who were negatively affected by the COVID-19 pandemic. 

The most common mistake he found in the résumés he reviewed was a lack of quantifiable achievements, with 86% of résumés having this issue, he said.

"Hiring managers and recruiters are looking for people who perfectly fit the role and are able to achieve goals and evaluate their personal impact.

The best résumé is the one that shows how you are perfectly qualified for the job to which you are applying,” he previously wrote for Business Insider.

how to write job stories

Watch: A résumé expert reveals what a perfect résumé looks like

how to write job stories

  • Main content


  1. 5 Tips For Writing A Job Story

    how to write job stories

  2. template 4 Job Stories

    how to write job stories

  3. Job Stories: A Viable Alternative to User Stories

    how to write job stories

  4. How to Write a Good Story (with Examples)

    how to write job stories

  5. 5 Tips For Writing A Job Story

    how to write job stories

  6. Replacing The User Story With The Job Story

    how to write job stories




  3. How To Write Job Description In Resume

  4. How to write job application letter # Accounting staff # MANHA EDUCATION # Shorts

  5. A Quick Method to write job descriptions for Upwork Jobs ✅



  1. Job Stories: A Viable Alternative to User Stories

    Tagged: product backlog user stories job stories As useful as user stories can be, they've never been right for every team. An exciting alternative for some teams is the job story. A job story is focused less on the user performing some function than on the job to be done by that story.

  2. The Key to Landing Your Next Job? Storytelling.

    The quickest way to land on the "positive" side of that equation is simple: Tell a good story on your resume, in your cover letter, and during your interview. Begin with your audience in mind....

  3. 5 Tips For Writing A Job Story

    Here are 5 tips which will help when writing Job Stories: Refine A Situation By Adding Contextual Information Job Stories Come From Real People Not Personas Design Modular Job Stories Which Features (Solutions) Can Plug Into Add Forces To Motivations Job Stories Don't Have To Be From A Specific Point Of View 1.

  4. Stop Rambling

    This involves two steps: First, deciding what narrative you want to tell, defining the major chapters of your career.

  5. How to Tell Your Career Story

    1. Your Beginnings Maybe you had an inkling—from a very young age—that you were a great salesperson or marketer. We all love a great career story that starts with the lemonade stand. You might recall a particular lemonade stand where you came up with a genius pricing strategy. Two lemonades for the price of one after 3 pm?

  6. Replacing The User Story With The Job Story

    When a task is put in the format of a user story ( As a [type of user], I want [some action], so that [outcome] ) there's no room to ask 'why' — you're essentially locked into a particular sequence with no context. Here's how I see the format: Assumptions and disconnect between their persona and action

  7. What Is a Career Story? (And How to Write One Effectively)

    To write a career story, you can consider what your skills, experience, knowledge, and values are. Determining this can help you learn more about yourself and your goals.

  8. Best Stories to Tell in a Job Interview

    6 Types of Stories You Should Have on Hand for Job Interviews by Kat Boogaard Updated 6/19/2020 Shutterstock You're prepped and ready to totally nail this job interview. You've rehearsed your elevator pitch—in front of the mirror, even. You've committed the entire job description to memory.

  9. User and job stories

    Step 4: Write acceptance criteria. Write acceptance criteria on the back of your index cards to measure how your content meets a user or job story. When you meet the acceptance criteria you have completed the story. For our readability example in the user story above, acceptance criteria might be that: content is in plain English.

  10. An agile leader's guide to writing user stories

    The Three C's: Card, Conversation, Confirmation. The Three C's formula, developed by Ron Jeffries, helps to reach agreement between the business and the technical team on the meaning of the user story. The Three C's guide them through the progressive elaboration of a story, from a brief statement to a fully developed user story.

  11. User Stories vs. Job Stories: What's Right for You? • intent

    Compared to the earlier User Story, the Job Story provides more context as to why the user wants chat functionality in the application. In particular, the user's pain points are much more visible than a User Story could show — and the team can focus on designing to eliminate that pain. When writing job stories, product managers should provide ...

  12. What are Job Stories and How are they different from User Stories?

    Put simply, we can say that Job stories are more concerned with motivation and outcomes rather than a user performing some function. Job Stories Template. A job story UX template or format comprises three key elements-1. "When" (the situation or the context) 2. "I want to" (the goal or motivation), and. 3. "So I can" (expected outcome)

  13. Sample Stories that Propel Careers

    by Katharine Hansen, Ph.D. Job-seekers need to know how to develop stories about skills, abilities, expertise, personal traits and characteristics, values, and accomplishments. Stories of various lengths and containing varying amounts of detail for each element of your job search: Short bullet-point version for your resume.

  14. Write a Powerful Career Story to Land the Job You Want

    Know what a career story is - and what it isn't. In simplest terms, a career story is a brief, chronological synopsis of who you are, what you do (better or differently than anyone else), and your essential attributes. It's a narrative that summarizes the value you bring to the table, conveys your passion, and explains why an employer ...

  15. Sharing a Career Story for an Interview (With Examples)

    Sharing a Career Story for an Interview (With Examples) Indeed Editorial Team Updated December 15, 2022 When interviewing for a new job, you can increase your chances of getting the role if you develop a good narrative that tells the hiring manager your career history.

  16. User Stories in Agile

    Define What They Want to Do: List the tasks they want to accomplish with your product or service for each persona. Write the User Story: Use the standard format: "As a [type of user], I want [an action] so that [a benefit/a reason]." This keeps the focus on the user role, their needs, and the value they get.

  17. The Cool New Way to Tell Your Story in Your Job Application

    The Cool New Way to Tell Your Story in Your Job Application by Erin Greenawald Updated 6/19/2020 Whether you're trying to explain a winding career path or are just a regular job-seeker looking for a way to stand out, telling stories may be one of the most powerful tools in your arsenal.

  18. How to Write a Good User Story: with Examples & Templates

    Feel some empathy. Give your "user" a name. Think of his mobile habits, what issue your app is going to get resolved for him and how you're going to make this path easier and faster. Remember some people who you know from the real life and who fit this portrait; feel how you relate to this target group.

  19. Job Search Tool #1: SOAR Stories List

    It's your SOAR stories list for interviews and resume writing. Even before you prepare your resume, start developing a list of accomplishments or "success stories" that illustrate your skills and strengths. You won't show this to employers, but you'll use it as source material for interviews, your resume and other materials.

  20. How to Write Better Construction Job Stories

    Effective storytelling is the differentiator in the heavy construction market where the competition is tight and your audience's time is limited. The person you're trying to reach may not have the luxury of sitting in front of a computer and reading articles during the work day. They may be working in the field for 12 hours.

  21. 8 Types of Useful Stories for Interviews

    Get interview-ready with tips from Indeed Prepare for interviews with practice questions and tips Types of stories to use for interviews Here are different kinds of stories you can prepare for your next interview: The time you met a goal Show employers you are a goal-oriented candidate by having this kind of story ready for your next interview.

  22. How to Write a Story In 6 Steps: A Complete Step-By-Step Guide to

    Step 1: Determine Your Setting Location is an enormously useful tool in novel-building. You should treat it as you would treat a character, allowing it to convey mood and letting it reveal more of itself over time. By selecting locations that excite you, you can transform relatively mundane scenes into more compelling ones.

  23. 8 Inspiring Stories of How People Really Got the Job

    8 Inspiring Stories of How People Really Got the Job by Lily Herman Updated 6/19/2020 The job search process can leave you tired and weary, especially after you've applied to dozens (and sometimes hundreds) of jobs with little or no response. Every once in a while, it's nice to have some inspiration to keep you going. What's the best job for you?

  24. How to use Microsoft Copilot in your day-to-day work

    Job Title * Phone * ... But you can also get coaching from Copilot on things like clarity, style, grammar, and tone. Just start writing an email, and then get an AI coach to give you feedback. After analyzing the email, Copilot will give you feedback and suggestions on how to write a better email. ... How about writing a short story about a ...

  25. User Stories vs JTBD

    What are user stories. A user story represents a piece of work that, once released, adds value to the user, as they use your product or service.. This piece of work, or story, should be split in a way that can be delivered independently and without a special sequence. The decision on how to write the user story should be defined and agreed with the team who will be designing, developing and ...

  26. A Former Amazon Recruiter Shares a Common Résumé Mistake

    An ex-Amazon recruiter says a key mistake job candidates make is writing vague statements in résumés. She compares these to "Miss America answers" that don't highlight specific achievements.

  27. Managers admit to using ChatGPT to write performance reviews

    Managers and employees are increasingly turning to ChatGPT to help write performance reviews, a task that can determine raises or job security, Axios reported. Managers and employees admitted that crafting these assessments can often be daunting or tedious, and the AI tool helps knock the annual task off their checklists.

  28. Fact check: Biden makes three false claims about his handling of ...

    President Joe Biden gave a press conference on Thursday night after the release of a report from the special counsel, Robert Hur, who announced that Biden would not face charges over his handling ...