← Home

Job Stories: My New Favorite Way to Capture Requirements

I didn't think 2024 would be the year I threw out User Stories in favor of 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're 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 an 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 the 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 to gain a deeper understanding of a user's needs. From there, user stories can be crafted that define specific functionalities.