Some advice on user stories

Why stories?

Stories are a powerful tool to focus our efforts on what customers really want and need. Like any tool, however, they can be used effectively or ineffectively. Following a rigid format like “As a [someone] I want to [do something] so that [I get some outcome].” is not an indicator of how useful your stories actually are.

Useful stories are told from the ‘outside in’, as we put our product into the hands of imaginary customers, trying to understand how they will interact with it, and how it will help them with a job-to-be-done in their lives.

Even this isn’t enough, though. Until we get some feedback these stories are merely the best guesses of the product development team; the imaginary customers might not actually exist in real life. It follows, then, that we want to turn stories into feedback that tests them - as quickly as we can. The simplest way to do this is to reduce the size of what we get feedback on; which is to say, we need to find ways to break our big overarching story into lots of smaller stories that drill into specifc scenarios and circumstances.

How we slice big stories into small stories is important.

Let’s propose two rules for the slicing of stories::

  1. Each story we slice out of a bigger story should describe something that we can get feedback on.

  2. We should be able to add or remove stories from our backlog without undermining the usefulness of what we are building.

These rules (especially rule 2) should prevent one of the obvious traps in breaking stories down: breaking them into technical or deliverable chunks of work disguised as meaningful user stories.

A story that talks about a customer navigating to a screen on our app, and another talking about a customer using that screen to do something represents how our team might feel most comfortable delivering the work but it don’t reflect the kind of stories a customer would actually tell us. Worse, we have effectively coupled them together - we have to do both before we get any useful feedback.

The user interface should follow from the stories (guided and constrained by prototype designs for sure) and not the other way around. Stories are there to help us understand what we actually need to build, and to provide a focal point for a whole-team co-creative process.

We need options not a task list

What we really want is a backlog of options to consider, framed in a way that lets us make prioritisation decisions, discuss trade-offs and have design debates. A backlog of stories should show me what different interactions, circumstances and scenarios are being considered for the product release we are building.  If we are constrained by time or money we might not even play all the stories we have in our backlog but we should be confident that when we complete each story, it leaves behind a new iteration of our product that is incrementally better than its predecessors.

Backlog refinement is continuous

Stories in the backlog aren’t set in stone, either. That’s partly why, traditionally, people used post-it notes and index cards to represent them. Backlog refinement is the continuous process of reviewing, researching, refining, splitting and removing user stories from the backlog. And as stories get into sprints (if you are following that planning approach) there is the opportunity to split them down even further.

Looking at an example

Here is an example breakdown showing how we could start to split out a big idea (the big story) into smaller, incremental stories. The representation as a mind map tree is to highlight the iterations of slicing we can conduct.


Screenshot 2019-04-24 09.58.38.png

Not every story has to be shippable

It’s worth noting that there is no rule that says every story has to be amazing and shippable to our user community. In fact, for new features and products, that’s really unlikely. We can instead think of a set of stories coming together to make something that is valuable and releasable. This is liberating, because it lets us play a bit with designing stories help address risks and assumptions - especially architectural ones.

For example, it’s generally good practice to build some kind of end-to-end integration of your new feature or product as quickly as possible; you might have come across the language of walking skeletons or tracer-bullet releases.

The way we frame stories can facilitate this. Using the money management example above, we could have a story that only focused on a new-to-bank customer (let’s call her Sally) who has only made a few simple transactions with hew new card. Her version of any of the stories above could involve a very simplistic implementation. Now, we know that Sally doesn’t represent all the customers we want to reach but she is real enough for us to build something that touches all the architecture from UI to database.

Every edge-case you think up is a new story for your backlog

It’s very common to have discussion that go along the lines of, “yeah but what about if [insert something] happens”. These edge cases can consume analysis, design, coding and testing time. They can cause a neat, short story to bloat into a huge and rambling ‘novel’. Instead of trying to expand the scope of the story we are working on by adding new acceptance tests, we could instead write a new story that captures the edge case or situation. We can prioritise it against other stories later, and concentrate on “banking” the story we were working on to begin with.