The user story has been the go-to Agile technique for breaking down requirements into manageable chunks for incremental delivery of work. The usual format is:

As a (user role) I want (to do this activity) so that (I get this outcome).

The job story is another technique I have come across that is a variation to the standard user story. The difference is that the job story format has situation, progress and outcome instead of user, activity and outcome. For example:

When (situation happens), I want this (progress made to outcome) so I can do this (outcome) This link provides more detail.  What I like about the job story is that it sounds more personable than a user story and therefore more understandable for our customers. According to the linked article a job story does not come across as presuming a solution while a user story can sound like it is. However the third person of the user story is helpful in making clear who the user or role is as it is crucial when designing solutions that a certain user type or role gets to see and do what they require. It is also extremely useful for user acceptance testing as it is very clear what has to be tested from the user role perspective.

Horses for courses, but for consistency I would recommend that only one or the other is used in a single project. Either method is “just enough” documentation which can only lead to improvements in our agile journey.