The ABC of Stories

Originally posted some years ago, republished and updated here because...

IT STILL DRIVES ME CRAZY!

One of the essential tools in the Customer’s armoury is the Story. Its a simple, easy and effective little tool. My four year old nephew could write them. So why is there so much material written about it? Why the endless blogs (guilty) and tedious articles on how to write them? I’ve even seen whole books devoted to the subject!

Fortunately, after nearly ten years of writing them, using them and most satisfyingly, tearing them up I can safely say that I know a thing or two about Stories. So, here is what I consider to be the essentials of writing good Stories. You don’t need to know anything else. (note: this is just about writing the story itself. I don’t discuss prioritisation, planning, releases or any other such horrors)

It helps to remind ourselves of what the purpose of a Story is. This will greatly demystify their production.

A story is a tool for product planning, its is an aide memoire for a small item that may eventually be part of the product. Its a little something that will jog your memory and remind you what needs to be done and approximately when.

That’s it.

Really. That’s it.

Its no more advanced or intricate than a post-it note and requires about the same level of thought. I’m sure you often use post-it notes and I’m equally sure you take very little time to think about their contents and in fact you probably just write what is obvious and minimal.

Here’s an example of a post-it note I wrote yesterday.

‘Pick up some cheese.’

Here’s an example of a story I wrote for an advanced product catalogue application a few years ago.

‘Display the non-VAT price.’

Spot the difference? No? I’m not surprised because there is none. One is reminding me to get some cheese (I have an addiction to cheese-on-toast) the other is reminding me to display the non-VAT price on the user interface of my product catalogue application.

Both of these took me about the same amount of think-time and approximately the same time to write. One I wrote on a piece of sticky yellow paper, the other in a row in a spreadsheet (can you guess which one is which?).

So, as I have just amply demonstrated, if you can write a post-it note for the shopping you can write Stories for an agile project.

You may ask:

‘But what makes a good story SJ?’

In fact, the two examples I have given have remarkably similar properties and are pretty solid examples of exactly what makes a good story.

They are mercifully short.

They tell me enough but with no details or specifics.

They could go in a list along with other Stories/Post-Its.

They would each be relatively small tasks.

My mother could understand them.

Lets look at each property in turn.

1) Good stories are mercifully short.

Thank goodness! Of all the things that a Customer or Product Owner has to do, by far the least important is paperwork. The shorter the story the less you have to think about it, the less you have to write and the less anyone else has to read.

2) Good stories tell me enough without any details.

Lets look at my cheese example. When I read this note tomorrow I will know exactly what I want and what I need to do. But, it is missing all sorts of information; what type of cheese, how much cheese, what brand, which shop. If I am very worried about my memory and if it is critically important, I might decide to amend my note to say:

‘Pick up some Cheddar cheese.’

But as Cheddar is my preferred weapon of choice when it comes to toasted cheese I think its unlikely I’ll forget.

And this is the essence of Stories. They are a tool for YOU. You the Customer. They are not for developers, they are not test specifications or design documents, they are certainly not for management presentations. They are for you and you alone and therefore should contain only what you need.

3) Good stories can go in a list. i.e. you can prioritise them.

In particular they should be items that can be ordered arbitrarily. Don’t think about this one. Anything can be ordered arbitrarily despite what your Architect or Project Manager might tell you. Its not your job to worry about how this is done. Just put them in the order of priority that makes sense to you.

4) A good story is a short task.

In my cheese example (assuming I am only going to get this one item), I can figure thats its going to take me a couple of hours. Travel to the shop, item selection, the dreary supermarket checkout, paying for the parking and home again. I’ve done it before and I can be reasonably confident of the two hour estimate.

Take the VAT example. As a Customer I’ve asked for stories like this before, so, using Yesterday’s Weather I can probably hazard a reasonable guess this will take the team a day or two. I’ll probably run it past them first, just to make sure there’s no elephant in the room, but most likely, its a pretty small task. If the team estimate wrong on something this small then how far wrong can they be? Even an inaccuracy of 100% is only going to be a day or two more.

The main reason for the size quality is that its pretty easy to work out the size of something small. So, as long as we keep the stories pretty small we can be fairly confident of the estimates provided. You’re setting up your developers to succeed.

Hang on though.. what if my story is too big, you say? Well, here’s the rocket science bit... tear it up and write two or more stories that are smaller but together do the same thing. I apologies for the complexity involved here, I promise the rest of this blog will be much simpler. :)

5) A good story is simple enough that my mother can understand it.

This is probably the most important criteria. Anything more complex probably contains too much detail (very bad) or is poorly understood by the author (even worse). You are likely to be discussing Stories and the product overall with a wide diversity of people very few of whom will either care or be able to understand the underlying detail. Keep ‘em simple.

Another element to this is the idea of story ‘fixation’. This phenomenon occurs when the Customer puts too much detail on a story too early. There is some property of the written word that creates in the minds of the readers something contractual, something binding. They ‘fix’ on the detail and then you find yourself in difficulties later as you try to explain that you’ve changed your mind.

The story should only express the ‘what’ or the ‘goal’. Avoid any references to the ‘how’ in the story. Here’s two examples.

‘Each time a user logs in remind them of their remaining balance.’

‘Each time a user logs in remind them of their remaining balance in the top left navigation bar.’

The first specifics the goal, the second is beginning to wander into the how. There are many ways we could tell the user and this detail is best left to the process of development.

That’s about it!

A story is just a placeholder, the details, whatever they may be, belong elsewhere. A child could write them, and if you happen to be developing software for children why not give that a go!

You have much more important work to do that agonise over Story structure.

Some questions you might have:

Q) But what about all the other stuff, estimates, actuals, priorities, details, acceptance tests etc.?

A) Don’t even worry about this stuff whilst creating stories. This is Meta-Data about the stories and will be applied later. You might want to know some of this info, but I’d leave it to your Project Managers or Scrummasters who enjoy this nonsense much more than you do.

Q) What about numbering stories?

A) My advice is don’t do it. There is no benefit in it for you at all. The problem with numbers is other people will use them as a key or index. This is fine until you scrap a story and write some new ones. What index will they use then? Do you want to maintain indirect indices, story lifecycle histories etc.? No, of course you don’t. Don’t be tempted to use stories as some kind of categorisation system for the whole project. I’ve done it and I would never recommend it to anyone.

Q) What about using the ‘As a User...’ story style?

A) If it works for you fine. I use it occasionally as it tends to remind me to keep out the ‘how’ and focus on the ‘what’. Just don’t be a slave to it. Most of the time a simple ‘display the time’ style will do.

Q) What should I use to capture my stories?

A) I like post-it notes, cards, fag packets; whatever comes to hand. Longer term you probably want to use either a spreadsheet (pretty popular with management types) or perhaps a wiki. Personally I think that Mind Maps make a create story repository and have many other benefits besides. There’s plenty of good software out there, free and commercial. What I would resist strongly is the use of any of the currently available agile planning tools. Don’t get suckered into it. Let project managers figure out what tools they want to use. You are the Customer and project planning ain’t your job! Once one of these tools creeps in you’ll find yourself pulled into a world of statistical pain, illusory projections, resource scheduling and all the other horrors of naive project management.

If I’m working in a very politically-oriented company then I may even be so mischievous as to avoid publishing all stories. I am the Customer. I decide what gets done and when and as I am able to change my mind frequently (and I will) then publishing six months worth of stories up front is just noise. Don’t do it.

Q) What about Theme’s, Epics and so forth?

A) Don’t waste your time. They don’t add any value. A Theme is pretty much just your management team’s high level goals. Don’t bother trying to link stories to them. Most won’t fit well anyway. As for Epics they are simply big stories. You’ll break them down when you need to and throw the original away. If you must call them Epics then fine. Just dispense with them as soon as you have replacement stories.

Q) But my developers are complaining there’s not enough detail to estimate?

A) You, and they, are missing the point. The detail required must exist somewhere, in documents, presentations, in you head. But it doesn’t belong in the story.

Trust me when I tell you that you can manage a huge project on nothing more than a board full of post-it notes. I’ve done it several times and on very large projects. In fact the somewhat counter intuitive notion to remember is that the larger the project the less complex your system should be.