So, you’ve heard of User Stories. They represent requirements from the perspective of a User. But that’s not the only kind of requirement there is.

The distinction between a Job Story and a User Story is the perspective from which the story is told. Primarily, Job Stories focuses on the situation or scenario in which an action will be triggered. This shift can give additional information that might be missed in the more traditional User Story format.

Format

The format for Job Stories is basically this:
When (a situation), I want to (motivation) so that (expected outcome).

Where User Stories focus on Who, Job Stories focus on When. Also, where User Stories state what is needed, such as a dashboard or report, Job Stories focus on actions to be performed.

It’s not that Job Stories are Superior to User Stories. But there are situations where to capture the intent of the work, you need to express it as a verb instead of a noun – or an action instead of an object. 

That distinction is where Job Stories are valuable.

Examples

Here are a couple of examples of Job Stories:

When I want to withdraw money from my bank account, I want to know I have enough money in my account to withdraw some now so I can go out to dinner with my friends.

When someone wishes to withdraw money from his/her account, the customer wants to know if funds are available, the teller wants to know if the person banks with us, so that the person requesting can received the desired cash amount.

Elements

As mentioned in the previous slide, the format is When (Situation), I want to (motivation) so I can (expected outcomes).

The Situation gives the trigger – when will this job happen?

The motivation identifies who needs to do what.  And it can involve multiple personas or actors.

The expected outcome can also be multiple.  On the previous example, expected outcome could be the customer receives cash and the teller reduces cash amount from the account.

Description

One of the benefits of Job Stories is how this technique relates the Customer’s motivation. It can help to Think as a Customer, and build empathy.

One of the things that has struck me while studying the literature surrounding various Agile frameworks is the use of terms like Empathy in explaining the purpose of various techniques. One of the major elements required to pass the AAC exam is the Agile Mindset.  So understanding the empathetic side of the analysis is very important. Requirements are for people, and they need to reflect the motivations of the customer. Empathy is a requirement of the Agile Mindset in order to “Think as a Customer.”

The context for this is Requirements Management and the audience is the Internal Team.

Usage Considerations

We’ve talked about the strengths, giving voice to motivations and focusing on tasks instead of objects.  Job stories are also great for cause and effect relationships, as well as capturing the intended User Experience.

We’ve not mentioned this, but you don’t have to use just one format for requirements.  You can use Job Stories and User Stories.  Or you could use Wireframes and Models, or other formats. 

However, switching things between multiple formats can cause some confusion.  And try to keep it brief.

• Agile
• BA Techniques