Job Stories vs User Stories: What's the Difference?

[@georgwagner5577]

Almost 9 mins of such great content - w/o ads. I loved it :) As a developer I prefer the Gherkin-Syntax for user stories. But job stories are a nice thingy. Thanks.

[@MountainGoatSoftware]

Thanks, Georg.

[@HKCS-yn5nc]

It's interesting to see how closely related job stories are to a user intention in essential use case dialogues, confirming my hypothesis that stories are just a subset of a use case dialogue

[@LegendaryMediaTV]

This video and your story mapping video are the reason I purchased your “Better User Stories” course. Clear, well organized, packed with info, and definitely speaking from experience. The course is the same way and well worth the price!

[@MountainGoatSoftware]

Thank you. I really appreciate that.

[@radreba]

This is interesting. It is the use of Gherkins User Acceptances added to the User Story.

[@olivierclop6061]

Hello Mike, Very interesting for sure. I'm going to check my PBIs to spot JS hidden behind US. It seems to me that JS can also be used as acceptance criteria because they can describe business ergonomic rules. However, I think that if too much emphazise is put on JS, we may forget about end users and little by little forget about the agile approach that requires frequent user feedback to adjust the devlopement plan so that we build the right product. I agree with you, each team has to find the right balance that fits its product. So we have to experiment and find the appropriate distribution, a bit like we already do with US, Enablers and Bugs. May be delivering a batch made of a US and its related JS to minimize the amount of work while, all in all, maximizing the actual delivered value...

[@MountainGoatSoftware]

It's definitely possible to get too far away from users, but I don't think that's a huge risk. A typical product backlog for me will contain a mix of some user stories and some job stories, which will help with that.

[@chriselliott3011]

I wrestled with this for a long time... There is a dogmatic approach to the use of user stories in some organisations and the job story offers an easy step for such organisations to be more pragmatic

[@MountainGoatSoftware]

Agreed. I'm frustrated when someone tells a team that _everything_ needs to be a story or to comply with any template.

[@michaelwagener1411]

Thanks, Mike - as a scrum master, I want to write job stories, so that I can be more accurate in describing the needs of my users... 😂 Job stories have not hit my radar yet, but I am glad that they have now. I can see just how useful they could be. 👍🙂

[@MountainGoatSoftware]

Nice story :) I'm glad these are now on your radar.

[@BenjaminScherrey]

Haven't heard of job stories before. Certainly have fought against using generic "user" as the primary stakeholder. Now I see this is a different context and job stories might be superior in those cases.

[@MountainGoatSoftware]

Yeah, any time sometime writes the same "as a user/member/whatever" ten times in a row, that's a sign that job stories would have been better.

[@HelenG-s3d]

Thanks Mike - this was super useful following our previous conversation last month. Our backlog now contains both types. Keep up the great work. ☺

[@MountainGoatSoftware]

That's great to hear. I'm glad you're using them.

[@clairefreshney4761]

Isn't "see a warning message" > Output focused? When JTBD is outcome focused? So rather than stating the output, we should state the outcome in job stories?

[@MountainGoatSoftware]

Perhaps. But too much is made of distinctions like "a story should tell the team what is needed but not how to do it." That's valid for larger stories. But by the time a story is made small (via splitting for larger ones) it's often appropriate to say something like "I want to see a warning message." By that time, debates about how are done. Leaving that vague too long just hides the real intent. At some point, we do know we want a warning message.

[@clairefreshney4761]

@@MountainGoatSoftware Interesting take! So for that I use tasks and acceptance criteria for the story - this helps to get into the nitty gritty. The tasks are what actions the user needs to take and the AC is for those points mentioned.

[@MountainGoatSoftware]

@@clairefreshney4761 That's a great way to get the nitty gritty documented for larger stories.

[@solomani-42]

First I’ve heard of this approach. Sounds useful.

[@MountainGoatSoftware]

Let me know how they work out for you.

[@hemantkothiyal6364]

I have a question Mike- how does job stories different than user story acceptance criteria (especially if I write them using Given When Then). I can elaborate user stories exactly like job stories by using acceptance criteria

[@MountainGoatSoftware]

The sub-stories that can be split out from either a job story or user story are equivalent to their acceptance criteria. Big stories get split into small stories. Small stories have acceptance criteria added rather than splitting them into tiny stories. So any sub-story can be thought of as an acceptance criteria to its parent story.

[@JohnSmith-fz1ih]

Thank you for your content. I really struggled to get on board with this video. The first reason is the examples are poor. Not being able to Accidently place an order twice should not be its own user story. There shouldn’t even be “not” in a user story. In this case, this should be in the acceptance criteria on the user story for placing an order. Having so much implementation details determined by the user story instead of just outlining the goal and allowing the team to come up with a solution is also a major issue. A product owner should not be specifying implementation details like “show a message”. In this case, if the feature is implemented properly in the first place you wouldn’t need a kludge like a message telling the user not to do something that the UI allows. That’s just all-round broken. As to the need for job stories, I was listening and wondering why I haven’t run into the problem that job stories provide. And it’s because I use the Gherkin syntax. In this, you list the pre-conditions. One can be that a certain type of user is logged in and taking a certain action. Which means I don’t ever have the problem job stories are solving. Put more directly: this video explains that sometimes you don’t want to list the user (ie. it should be an optional field). And “when” should also be an optional field. Well Gherkin user stories give me both of these options out of the gate, I don’t need to mix and match user stories and job stories.

[@MountainGoatSoftware]

Gherkin syntax is great for testers and beyond. I do not find it useful for early story writing with stakeholders because it's not a very natural way of speaking. As for "can't place an order twice," if that is simple, it should be (as you say) an acceptance criterion. If, as is more likely, the work to do that is enough to do will reduce the size of the parent story, consider moving it to a separate story. Acceptance criteria and sub-stories are interchangeable. The substories are worth splitting out when doing so makes it easier to fit the parent into a sprint or when some substories are of much lower priority, in which case they can be deferred.

[@devinhedge]

Nice to see a 10 year old idea finally getting sunshine and traction.

[@zonegamma8197]

Good video thanks

[@MountainGoatSoftware]

Thank you very much.

[@rajeswarikv9396]

This is a new learning..Thanks Mike for sharing

[@MountainGoatSoftware]

Thank you.

[@TiffannyDoll]

Job stories look like acceptance criteria.

[@MountainGoatSoftware]

I understand how those similarities can be drawn. However, Job Stories and Acceptance Criteria serve different purposes. Job Stories focus on the situation, motivation, and expected outcome of a user's interaction with a system. Acceptance Criteria are specific conditions that must be met for a User Story, or Job Story, in order to be considered complete. While both add detail and context to the development process, Job Stories are about understanding the user's needs and motivations, whereas Acceptance Criteria are about defining specific requirements for completion.

[@TiffannyDoll]

@@MountainGoatSoftware thanks so much for taking the time to reply. I appreciate it