What Makes A Good Story?
Having established that the quality of our user stories is important, how can we ensure that the stories we're writing are up to scratch? It's one thing to be able to measure whether you're succeeding after the fact, but what we really want is to have some guidelines to follow so that we can avoid potential problems from the beginning. For this, it's useful to look at why they're called "user stories".
First, let's look at the word "user" in "user stories". That word shows up a lot. I've lost count of how many stories I've seen that start "as a user...". This is, quite frankly, a bad start. When you read a story, or watch a movie, the main character is your connection to the story. If that character is relatable, then you're able to appreciate what they're feeling, and think about how you might respond in the situation they're facing. This is exactly what we want from a user story. By definition, everyone who uses our software is a "user", so this tells us nothing - we need something descriptive. They might be a shopper, or an HR manager, or a helpdesk operator. These titles get you thinking about the person using the system, and hint at what their needs might be, but you can go further than this with the concept of personas.
A persona is a brief description of an imaginary person who might use the system we're building. At its most basic, it describes roughly what sort of thing they're doing that means they come into contact with the system, and what they want the system to do for them. Often, you'll get further details such as demographics, usage patterns, level of competence etc. Some of these are there for flavour, to make the imaginary person feel real, while others are there to drive the design. Good examples of the latter might be the user's goals or aspirations in their job, or their gripes and annoyances with the current system. It doesn't take much detail to start painting a picture of a potential user in ways that can guide how we build the application. This persona can then be used as shorthand, a quick way to unambiguously refer to a certain kind of user in discussion. When we read a description of a planned feature, we can start to think about it in the context of this persona - to look for ways it might help them to reach their goals, or whether we could make use of their skills, or need to cater to their weaknesses.
Lesson one: Remember who your users are; put yourself in their shoes, and look at your software through their eyes.
Now that we've got a character, let's look at the "story" part. The word "story" evokes mental images of books and movies, and that's not a bad place to start. Think of a user story as a book's blurb, or a movie trailer. Its job is to set up the tale you're about to read or watch. The format is pretty consistent:
- We are introduced to one or more characters
- The characters want something
- There is something preventing the characters from getting what they want
The story is then the tale of the character overcoming the obstacle to succeed at their goal. An Agile user story is exactly like that:
As a main character, I want to overcome an obstacle so that I can succeed at my goal.
Framing it this way makes one thing very clear: when the character succeeds at their goal, the story is over. The same is true of Agile user stories: the goal is to solve a problem. This means that you won't get a story like this:
As a roguish young orphan, I want to find a magic lamp, so that I can make three wishes.
You'll probably recognise this one, and if you do, you'll know that finding the lamp is only the beginning of that particular story. The problem was not solved by merely finding the lamp; it was solved by using the lamp to do other things. The real story is more like this:
As a roguish young orphan, I want to have my wishes granted, so that I can become a prince.
See how the whole focus of the story changes? The problem is stated, and the story describes how the problem is to be solved. By doing this, the character's motivation becomes much clearer; we can make the link between where the character is now (an orphan) and where they want to be (a prince), which means that if we see another, better way to make that happen (say, the princess falling in love with him) then we can choose to do that and still make the customer happy - in fact, happier than they would have been with the first option.
This is something that I've seen many developers miss, or forget. It's all too easy to focus on the problem, and not the goal - and that's quite understandable in an industry that is basically applied problem-solving. What's much more important, however, is to look at what the user is actually trying to achieve. This is probably clearer with a real-world example. I remember a backlog refinement meeting where we had a story like this:
As a marketing manager, I want a web management portal, so that I can input voucher codes into the system.
On the face of it, this sounds reasonable, but what's the goal? What does this story give you? Complete this story, as written, and you've got a web portal that lets you add rows to a database table... which just sit there, taking up disk space. Clearly, there's more to this story; something else has to happen to make this useful.
After some discussion, we'd re-written this story to look like this:
As a marketing manager, I want to store voucher codes, so that they can be redeemed by customers.
Now we see the goal; something that has value to the business. This seems like more work - and I'll be honest, it was - but that's actually a good thing, because it gave us a much better idea of how much work would be required before the system started providing business value, and it made sure we were focusing our efforts in the right place (more on that later).
Lesson two: User stories describe a process required to reach a goal, which is usually to solve a problem. Don't fall into the trap of writing stories that describe the steps taken to complete the process. In other words, a user story should be a complete, self-contained, atomic unit of functionality that provides measurable value. Keep asking why the user wants to do the action described in the story until you find a point where the user has done something useful, rather than simply being able to move on to the next step in a process.
Less is more
When you start thinking in terms of personas and their goals, you'll naturally start to look further down the chain of action and consequence when writing stories, and this will tend to pull things together into larger stories. We saw this in the voucher management example - what started out as a story that could be implemented by a web portal and a database quickly turned into one that required a web portal, a database, a REST API, and new features in multiple client applications. This looks like a problem - after all, weren't we saying earlier that small, composable building blocks are better than large chunks?
The solution, once again, is to focus on the goal. Once you've added in all the things required to actually get you to a useful outcome, take out all the things that aren't. Let's go back to the voucher example. Initially, the team started discussing the web portal, and the features it could have to make voucher code input easier - UI features, bulk file upload, smart validation etc. When we stopped and re-wrote the story, however, we quickly realised that all that could wait - it doesn't matter how fast you can add vouchers to the system if nobody can actually redeem those vouchers. Instead, we started by implementing a very basic web page - little more than a single HTML form with a handful of fields - which made use of a tiny API with only a couple of endpoints, which in turn stored vouchers in a tiny database that had a single table with something like four columns.
This had two key effects. First, it slimmed the story back down into something manageable, so we were able to fit it into one sprint with a little room to spare. Second, it gave us a system that was complete enough to start user trials, which gave us valuable feedback from the marketing department who used the portal, and the customers who used the redemption features. This feedback helped us to decide which of the stripped-out features the users wanted most, so that we could add them back in in the order that gained us the most value in the shortest time. Each of these features became its own story, each of which met a specific thing that the users wanted, and could be implemented independently of the others. It also let us drop a few things entirely - the users never requested them (or even seemed to notice their absence) so we saved ourselves some time by never implementing them!
It's also worth noting that as a happy side-effect of all this, we were able to deploy our basic version early, which meant that the customer had something that met some of their needs way before the project was actually finished. This can buy you time and goodwill to finish the rest of the project, as well as the obvious benefits of solving problems sooner. This the classic "skateboard, go-cart, car" metaphor in action. Each time you finish a story, you get something you could give to a customer - something that they can use and give feedback on. That thing might even solve the problem all by itself. If you hand the customer a skateboard, and they tell you it does everything they could possibly need, you can save yourself all the time and effort it would have taken you to build an entire car, and go do something more useful instead!
Lesson three: Start with a minimum viable product: the absolute smallest and simplest thing you can make that still solves a problem for the user, or improves their experience in some way. Once you have that, add small, discrete improvements to it (prioritised based on the user's needs) until you've done everything the user wanted (or it stops being cost-effective to keep going). If you're having trouble breaking things down any further, always build a complete solution to part of the problem, rather than a part of a solution to the whole problem.
While they may seem obvious in retrospect, these techniques can help to solve some issues that I've seen numerous times in real-world cases. Applying them consistently can take a little discipline, particularly when the stories you've got are "mostly ok". Sure, you could probably work on them as they are, and you probably wouldn't run into any serious issues, and the temptation is to just get on with actually building something. That's understandable, but you may still be missing out on the benefits of really good user stories. Perhaps the story is just a little bigger than it needs to be, so you'll be spending longer on it than you might need to; perhaps it's a little vague on the value of the scenario, causing a potential enhancement that your users would love to go unnoticed, or perhaps it has a few dependencies you didn't uncover, which makes it hard to pivot and react in the face of unexpected developments. Be strong and stick at it; in time, it'll become second nature to scrutinise your user stories for the warning signs I've outlined - and others that you learn to spot along the way.comments powered by Disqus