Uncover the ‘when’ and ‘why’ of your technology with job stories

Thousands of teams use ‘user stories’ in their system and product design process, and sometimes to great effect. However, user stories actually have a very specific role and context in which they are useful. Often they’re used by people who don’t know when they’re appropriate and, frankly, their use is often motivated by a desire to look professional and modern, not by a belief they are the best tool for the job.

Wait, what is a user story?

User stories are a format for capturing requirements. They have the origins in agile software development, but are often used in other contexts too. They describe a software feature from the perspective of an end user.

They certainly have their merits. In complex projects, the teams developing technology can get lost in their own world and user-centred design is easily forgotten. User stories can help keep discussions in the team focussed on the end user.

User stories follow a format:

What’s wrong with them?

The problem with user stories is that they focus on the less interesting parts and often include redundant information. There’s not room to ask deeper, more useful questions like ‘why’ or ‘when’ or ‘what triggers this to happen in the first place’.

The role/persona part is often useless. I see a lot of user stories where the role/persona is “user” or “administrator”. Does that really add anything useful? I think not, but people still spend the time to write out tens of user stories so they can say they’re doing agile software development.

User stories also include a lot of assumptions, particularly that the action is the most appropriate thing to do. It locks you into a certain feature or way of your technology working very early on and shuts down ongoing discussion.

Job stories: a better way

When we work on software projects, whether selecting and configuring off-the-shelf software or creating bespoke applications, the most useful questions to ask are things like ‘why would someone want to do X’ or ‘what triggers this to happen in the first place’. It’s the ‘why’ and ‘when’ which is conspicuously missing from user stories.

We therefore eschew user stories and use job stories instead (if we use anything at all — sometimes these tools are not appropriate and using them for their own sake is a waste of time and money).

I first came across job stories on Alan Klement’s excellent blog. They have a different, much more useful format:

This helps us focus on causality and motivations, two areas which are harder to dig into but much more likely to help you create technology that truly impacts your organisation or users.

To take an example from Alan’s blog, look at the difference between a user story and a job story:

User story:

As a moderator, I want to create a new game by entering a name and an optional description, so that I can start inviting estimators.

Job story:

When I’m ready to have estimators bid on my game, I want to create a game in a format estimators can understand, so that the estimators can find my game and know what they are about to bid on.

Hopefully you can see how the job story encourages one to focus motivations, triggers and context rather than obvious, low-value details.

Read more

I encourage you to go and read this post which goes into job stories in more depth and includes links to further discussion on the area.