I didn’t think 2024 would be the year I threw out User Stories in favor for something new. But here I am, unable to stop talking about their replacement: job stories.
Let’s take a few steps back. What is any of this?
User Stories have been the cornerstone of software development since the dawn of agile. They focus on what the user wants and how they will interact with a product or service to achieve that goal. They are meant to be a user-focused way to capture requirements and have a very prescribed format that is easy to understand and unambiguous to interpret.
As a [role or persona] I want to [action] so that [benefit].
Cool. Nice. Sweet. So what’s wrong with them?
Much of the time, the differences in the users are not important if they all share a underlying motivation to reach the same goal. Why should we classify users into separate roles when each classification wants the same outcome?
Most of us understand the shortcomings of user stories on a visceral level. A common ‘smell’ I see is an over generalization of users. The user stories either start with “as a user…” or the same action and benefit is repeated over and over again with different types of users.
As a user (student, prompt engineer, hacker) I want to seamlessly compare LLM output with relevant information from trusted external sources (e.g., scientific journals, credible news websites) so that I can quickly assess the accuracy and reliability of the information and make informed decisions based on a broader context.
It feels silly because it is: a user story is not the right tool for these scenarios.
Enter job stories.
Job stories focus on the underlying reason a user wants to complete a task (job), and motivation behind it. It moves the focus from the differences in users to the impact of situations.
When [situation], I want to [goal] so that [outcome].
When I’m working with a large language model (LLM) and receive an answer, I want to verify its accuracy and ensure it’s reliable information. This way, I can trust the information I’m using and make well-informed decisions.
See the difference? The focus shifts from the perceived benefit to the person to the intended outcome of the job. It’s subtle, but much more effective.
Ok, so I should throw away user stories? Naw.
“Job stories” are just another tool in the ever-expanding world of requirement capturing. There are several applications in which users in different roles have very different goals and outcomes. For that, user stories are still a strong candidate for effective requirement gathering.
Want to go deeper? Ship user stories and job stories together.
User stories define what users want to do. Job stories uncover why they want to do it.
Start with a job story the gain a deeper understanding of a user’s needs. From there, user stories can be crafted that define specific functionalities.
User Story:
As a researcher who frequently relies on large language models (LLMs) for information retrieval, I want to integrate the LLM’s output with a functionality that allows me to compare it with relevant information from credible external sources (e.g., academic databases, scientific journals) so that I can efficiently validate the accuracy and completeness of the information provided by the LLM.
Job Story:
When I’m conducting research and using a large language model (LLM) to gather information, I want to be confident that the information I’m getting is accurate and reliable. This way, I can ensure the quality of my research and avoid basing my conclusions on potentially false or incomplete data.
This cases dives down into a specific role, the researcher. See how powerful they are when working together?