The System Story and the Job Story are two alternative formats to describe Product Backlog Items (tasks in a backlog) when the User Story format does not fit. Examples include technical enhancements, enablers, and when the work is done for a particular User Persona.
What’s wrong with User Stories?
When I work with teams on writing User Stories, the question always comes up: “What are different formats for Stories?”
The User Story is a format to write work items in a Product Backlog and it is used to shift the dynamic between Product Owner and Developers by fostering a conversation. User Stories help a Scrum Team to become more collaborative, to foster innovation, and to deliver better solutions.
User Stories help to frame tasks and work items from a customer’s perspective. By doing so, they help everyone on the team develop a deeper understanding of the customer needs, and foster a conversation on how best to solve that need. Hence, the User Stories should be written from the customer’s point of view.
Things get weird when User Stories are written like:
AS a Product Owner, I WANT to create xyz, SO THAT my customers can do abc
What’s wrong with this story? The Product Owner is not the user! The Product Owner is not the one getting the benefit from the story. They are just requesting the work.
Or consider this:
AS a Developer, I WANT to improve xyz feature, SO THAT my customers can use it
What’s wrong with this? The Developers are those doing the work, not the end-users (unless the work is done specifically for the Developers, like installing a new development tool for them to work better).
How to improve then?
Well, first, always write the User Story from the end-user’s point of view. Not from who’s requesting the work, not from who’s doing the work. From the end-user who will use the end-result of the work once completed.
Consider also that User Stories are not the only way that you can write work items in the Product Backlog. Consider in fact the System Story and Job Story formats.
The System Story format
The System Story format is useful for any internal work, bug solving, and performance enhancement work. This includes any “Enabler” work item to improve the system or extend the architectural runway.
The focus of a system story is a particular action to be taken to achieve the desired effect.
A System Story has similar elements of a User Story, but describes a particular action to achieve the desired outcome. The basic format of a System Story is:
<ACTION VERB>
<SUBJECT>
So that <WHAT> or <GOAL> is achieved
For example, if one work item is to upgrade the database server to the latest version for increased security and performance, we could write this work item in System Story format:
Upgrade
Database to the latest version
So that we increase security and performance of our system
The Job Story format
The Job Story is another format that is useful to represent the customer’s needs and create context about a scenario. The Job Story fits nicely to represent work items using Job-To-Be-Done. This makes it clear what job the end-user expects the system to perform to solve their needs.
Jobs-To-Be-Done (JTBD) is a product development approach that states that customers don’t buy products, they buy the jobs the products help them complete. For example, someone might buy a screwdriver to help assemble furniture. The “job” is to assemble furniture. The screwdriver is doing the job for the customer.
The theory is based on the idea that people buy products and services to get a “job” done. Job-To-Be-Done is a powerful approach to describe functionalities and work items as it enforces a focus on the customers and their specific needs.
Hence, we could use the Job Story format to write work items in a backlog, instead of User Stories. The Job Story format is:
WHEN [situation]
I WANT [action or activity]
SO THAT [objective to achieve]
The situation provides context on when the story is being performed or perhaps what triggers the story. For example:
- WHEN an order is submitted…
- WHEN paying by credit card…
- WHEN I am the store and realize I forgot my wallet at home…
- WHEN looking at recent orders..
The Job Story implies there is a clearly defined customer that needs the job done. Therefore this format is useful when the user or customer is well understood – for example, when you have a clearly defined User Persona and you are developing a series of features for that Persona.
A full example of Job Story:
WHEN I submit an order,
I WANT to receive a notification in email
SO THAT I can save a record of my orders and avoid re-ordering
Instead of repeating the name of the Persona in every User Story, you can use the Job Story format. It’s clearer, and it adds more context about the situation in which the Persona finds themselves.
Stories are not requirements
Now, regardless of the specific Story format you use, remember that User Stories/System Stories/Job Stories are not requirements. Requirements specify what needs to be built and (often) how to do it.
Stories specify what the user needs to do or achieve, and why that is important to them. How specifically to do it, or how to build it, are not specified in the Story, instead they emerge as part of the conversation between the Product Owner and the Developer.
Unconvinced? Jump to the User Stories are not requirements article.
