If User Stories do not work for your team, it is probably not because your team’s work cannot be expressed as a User Story. It is because you are not starting with the user. You are starting with yourself and your team’s work.

The purpose of user stories is to provide context to why something should be worked on and what value will be created for the recipient - the user. User stories encourage to focus on user benefits. If the work to be done does not provide any direct user value on its own, it is impossible to write a user story.

I will use a contrived example to avoid the technical nitty gritty of digital products. My apologies in advance to anyone who actually knows something about plumbing.

A proper User Story

In my book, a user story would look something like this:

As a home owner
Who needs to do dishes
I want to have
Running water in my kitchen
So that I
Can save time getting water from a well.

Each component of the User Story provides a piece of information about the target group, their requirements/needs, the solution and how someone in the target group will benefit from the solution.

From here, a plumber would define what tasks need to be done in order to get their client’s request fulfilled.

• Run a pipe from the water mains into the basement
• Run pipe from the basement into the kitchen
• Install a water tap above the sink

Not a User Story

The reality tends to look different. Somebody in the organization has the valid idea to save time on doing dishes. They ask a team to run pipes from the basement to the kitchen. While the team might be aware of the end goal, doing dishes faster, they are not asked to work towards this goal. Their job is it to put pipes into a wall. But the pipes alone have no value to a user - the home owner.

Meanwhile, the team is supposed to work in a user centric fashion. So they will try their best to fit their assignment into the requested format:

As a plumber
Who works for a home owner
I want to
Put some pipes into a wall
So that
Somebody can do something with them at some point.

This is not a user story. It’s a plumber story - at best. Actually not even that. It’s one task to be done to achieve something bigger. But it does not provide user value on its own and putting it into a user story format does not fix that problem.

The problem at hand is a symptom of:

• Projects that are too big and too complex so that they require planning too far into the future
• Focus on technical solutions to be implemented instead of focusing on adding user value in small increments - one story a time

What to do

The only remedy is to enable a team to change the scope of their work and their mandate. This enables them to work towards the final goal and the bigger picture - not just some piece of the puzzle. As a result, they are able to deliver user value with every story instead of delivering isolated technical solutions that only benefit users once they are put together.

If that is not an option, everybody might be better off to accept that the team cannot work in a user centric fashion for the time being, instead of shoehorning technical fulfilment into a User Story format.