Why user stories belong in the garbage

User stories have become ubiquitous in software development. We write and phrase everything as user stories. But in reality, we don’t live our lives in stories; we tend to think in terms of carrying out tasks like sending an email or buying the weekly online shop. And while the information that user stories contain is useful, that disconnect between the story and the reality of the way users think has made me wary about our reliance on them.

In fact, I’d go as far as arguing that user stories should eventually end up in the garbage. When I’ve read others propose this idea, I’ve found it strongly resonates. Like them, I’m not trashing user stories completely – they have a valuable role in enabling developers to have the right conversations – but they also have a lifecycle. User stories are of the moment, and they do not need to live forever.

What are user stories?

Defining a user story is not hard, though it may be difficult, even impossible, for everyone to come to a consensus. There are entire alliances of people who have got together to address this question in excruciating detail. Instead of giving a detailed answer of what a user story is and getting caught up in navel-gazing semantics, I’d like to offer a description of the lifecycle of a user story.

To begin, I want you to understand what I think the purpose of a user story is, or at least what I believe its scope to be – when it is useful, and when it stops being so. The question of when a user story stops being useful is the most informative, but in order to understand the death of a user story, let’s understand its birth.

Change conception

Let’s explore how we typically record a problem that a user has. And there is always a problem. In fact, there are a lot. The problems are multivariate — something isn’t working, or works unsatisfactorily, or doesn’t exist — and something needs to be done to solve those issues.

We all know the solution to the problem is coding some software, but we also know that writing code is incomplete solution thinking. So, we need documentation! Let’s document the problem. But how? And where to start? Let’s begin with the person who has the problem. She can tell us what’s wrong.

So, we ask the person with the problem for more detail. It turns out, as expected, there are many problems and they all differ in depth or complexity. We ask her to document her problems, and she creates a list. For some developers, this can make depressing reading which highlights the problems with the solution, and it can even feel like she’s demeaning the development team’s previous efforts! Most importantly, the list doesn’t describe motivations or reproducible behaviour. So, what do we do? We write user stories!

‘As the person with the problem, I want to use some new or augmented thing to solve my problem.’

Great! Well… pretty good. It’s a start. At least it’s not a depressing list of broken and missing features. Instead, stories are well-motivated and reasoned, and phrased proactively so we can feel good about our upcoming work.

Further, we no longer need to talk to the person with the problem as we already know her desires and motivations. We can go away and code, and we’ll just tell her when everything is done. So, we should start writing the code, right? Well, not so fast…

Teamwork and distribution of responsibilities

The problem is that we now have some information, but we’re missing an actual list of things to be done, which is crucial. But what kind of list do we need? Because we work in a team, it needs to be visible to everyone, clearly stating responsibilities belong to whom and when, and in what state each task is. So, we use a board. But what do we put on it? User stories?

Of course not!

User stories describe too much. In particular, they have ‘who’s and ‘what’s and ‘why’s and sometimes ‘how’s and ‘when’s too (that’s a lot of ‘and’s). None of those things describes what actually needs to be done by any given team member.

So, we get together and chat. ‘What actually needs to be done to satisfy this story?’ This is where we get into creating tasks. Tasks are the individual units of work necessary to get larger units of progress completed. We take the user story and, as a team, have a conversation to break down each story into tasks. It’s the tasks that we put on the board, not the stories. Now we can get to work.

It’s worth pointing out that dividing a user story into tasks isn’t purely a divvying up of the work at hand. It’s actually an important piece of analysis that translates the user story into action and involves insightful discussion and debate. It’s only by breaking the story into tasks that we can go through the user story mapping process, for example. In my experience, these task-based conversations have real value.

The end of a story

But what about the user story? What happens to that? If you ask me, you destroy it.

If you put the story in your icebox/backlog/cooler/hat, it’s time for it to go. It’s now duplicate documentation. That story was only there because you were yet to break it down into tasks. Now you have, so you delete it.

I don’t mean tick it off as complete, I mean right-click on it and hit the ‘delete’ button. It may seem harsh — after all, that’s how the original issue was communicated, and it informed your task list. However, it is no longer informative.

Why? Let’s be honest about the role of a user story – it’s just a placeholder for a future conversation while we’re collecting data about how a system needs to work, what it needs to output and for whom. Once we’ve had the conversation, the components of the story should have been documented. This renders the original user story irrelevant. Keeping it alive is meaningless, and often distracting. And no, it’s not particularly good for documentation.

It’s important to remember that a user story is not documentation. It’s a bit of a tautology, but it’s worth noting that documentation of how the system works is documentation. The change log is documentation of what has changed. In this kind of thinking, user stories are documentation of change yet to come.

But what about retrospective value?

One argument about retaining user stories is that they provide useful context for the next project team and future development. But apart from shining some light on the internal development process itself, perhaps promoting a flicker of interest, they don’t really offer anything of substance.

User stories are projections of desire. They don’t offer retrospective value because they are written before anything happens. We may deliver a perfectly fine product, but still never achieve any given user story; requirements change over time, better solutions are found and users’ roles sometimes change before their stories are ever satisfied. Those only matter if we treat the history of user stories as a source of truth.

Essentially, user stories are a record of what was intended to happen, not what actually happens in the development; using them as a starting point for further work only provides a distortion.

Having said this, there are two places where user stories can live more indefinitely. One of these is in the backlog where they can create places for conversations that you’re not ready to have yet, and you can continue to update user stories with requirements, acceptance criteria and so on. User stories might also have an effective shelf life as a label for a release, although that will depend on the nature of the release.

There’s also a place for user stories as epics. For example, JIRA epics are effectively user stories, albeit at a slightly higher level, which are intended as collections of other more granular user stories. Once you discard the latter, you can keep your epics around.

Towards user story lifecycle management

The correct lifecycle of a user story is to collect data, write stories, gather as a team to discuss the stories and create tasks to satisfy them before deleting said stories and moving on to completing the tasks. User stories are simply documentation of a pending conversation.

Once the conversation is had, we need to document the outcomes and progress into the next section of work. If you want to communicate back to the users what has changed, you have a change log. Document the new possibilities and behaviours there. Not ‘As a subscriber, I want to…,’ but ‘Now subscribers can…’

Carrying out proper user story lifecycle management like this means you can start to improve development cycles; for example, when you get to the point of ditching the user stories, how do you feel about dumping them? Because if you sense that you’re going to lose important detail, it may be that you haven’t had the right conversations or derived the right tasks. Considering whether you’re ready to bin the user stories can be a useful checkpoint.

Fetch the bin

There is a tendency to treat user stories as the gospel source of truth, and the suggestion to delete them can raise some eyebrows. But we’ve grown to be over-reliant on them. If you look back to the Agile manifesto or Scrum Alliance training, user stories are designed to document the desires of users, not actually document how a system works. If you handed somebody a list of user stories and said ‘here’s how our system works’, they wouldn’t understand it. Ultimately, our records and documentation are designed to aid in understanding.

So, it’s okay. Bin the user stories.