User Stories Vs Job Stories. What works, What doesn’t?
The Standard User Story template has been around for a long time now & a lot of BAs, Product Owners swear by it. However, sometime back, the folks at Intercom came up with ‘Job Stories’ which was a great way to include scenarios in the stories. I’ve been writing User Stories & Job Stories for a while now with different teams & let’s break down both formats & see if there is a more effective way to writing these stories.
What is a User Story?
[As a <persona>] [I want to_______] [So that________]
‘As a ______’ focuses on the persona or the role, ‘I want to ______’ focuses on the motivation & ‘So that ______’ focuses on the reason or the desired end result.
User stories are about all of the persona/role who interacts with the system or who realise some value or benefit from the system. Not all personas mentioned in the user story are end users.
However, as this format is more role or persona centric, the situation where the story is defined tends to be ignored. A good user story would usually have a scenario where the requirement is needed. That said, the format doesn’t force the situation to be enforced in this case.
What is a Job Story?
[ When <scenario>] [ I want to _____ ] [So I can _____ ]
When ____’ focuses on the scenario, ‘I want to ____’ focuses on the motivation, and ‘So I can ____’ focuses on the reason or the desired end result.
A Job Story is scenario or context driven, where it helps the team working on this story visualize the scenario for a holistic approach. However, it doesn’t clearly define the persona or the role, which is could be a challenge in certain cases.
I’ve noticed that either of the above formats works great for a lot of teams that I have been a part of. I’ve also noticed that both these templates sometimes cause ambiguity for the developers reading the story for the first time as the templates force the BA or the Product Owner/Manager writing them to miss out on a few details which could easily be added in.
What format has been the most effective?
We’ve observed that a hybrid of both the User Story & Job Story has been very useful which minimises a certain level of ambiguity while the Dev reads it for the first time.
[When a _______ ] [<Persona> should ________ ] [So that _______ ]
When ____’ focuses on the scenario, ‘<Persona> should____’ focuses on the user/role action or motivation, and ‘So that ____’ focuses on the reason or the desired outcome.
The slight tweak in including the persona action gives the format both a situation of the requirement & the user action & motivation behind the ask.