What is a Job Story?

​Differences between user story and job story

What are the differences between a user story and a job story? In other words: when does the use of which approach make sense? To answer these questions, we first take a look at the user story:

• A user story is about WHO does WHAT and WHY.
• WHO is the role, i.e. the user, customer, requirements analyst, cinema audience, project manager etc.
• The role is at the beginning of the sentence and thus the perspective of the role is emphasised. This perspective creates the basis for an understanding among the developers. This understanding is important in order to later implement functions for the WHAT, to achieve the WHY.
• And of course the acceptance criteria must not be missing. They are considered the link between user stories and test cases and are usually obtained by questioning key words, i.e. verbs, adjectives and nouns.

Sounds pretty simple, doesn’t it? So why should the use of a job story be useful? There are two main reasons:

1. In many developments, countless user stories are formulated for one and the same role. The role itself thus loses its meaning, it does not contribute to the change of perspective and it does not increase the understanding of the people involved.
2. The situation in which the story takes place, in which the role or actor takes action to achieve the desired result, provides additional information. This contextual information is very useful for the understanding of those involved. Imagine, for example, that you are sitting in your home office and want to participate in a video conference right away, but the sun is blinding you. “If the sun is blinding and I’m participating in a videoconference, I want the brightness of the display to automatically increase so I can see what the presenter is showing.” So the information that the sun is blinding you while conducting the videoconference is much more important than the information about the role you are participating in the videoconference.

Tips for working with job stories and user stories

From these findings, some tips for working with job stories and user stories can be derived:

• If you develop a product where the needs of the users differ in essential points (and thus the roles become more important), you should formulate user stories as usual. The emphasis is on the role that carries out an action in order to achieve a benefit. User stories are made for exactly this purpose. They tell a short story from the perspective of a role.
• But if you develop a product where the needs of the users do not differ significantly, you can formulate job stories. They focus on the context in which a user does something to achieve an expected result. Job stories tell a short story that takes place in a concrete situation.
• Mixing job stories and user stories into a common story can make sense: If <situation> I want to be a <role> to achieve <benefit>. This is obvious, especially since there are alternative user story templates.

An impulse to discuss:

Job stories could be a useful alternative to technical stories.

Notes:

Mike Cohn – one of the founders of the Scrum Alliance and author of “Agile Estimation and Planning” – recommends the joint administration of job and user stories in the backlog. Everything else would be strange, because epics, features, spike stories etc. are already managed there. In addition, Mike Cohn advises to formulate job stories whenever you want to write a batch of user stories that all start with “As a user …”.

Job stories are also mentioned in the context of Jobs to be done (JTBD). JTBD addresses the needs that a user really wants to fulfill with a product. You can find a blog post about this here.

More interesting articles and discussions can be found here and here.

Here you will find additional information from our Smartpedia section:

What does t2informatik actually do? One click and you'll know.