When I’ve talked to various people about the art of writing stories they often say that they have trouble breaking them down into small enough pieces. One former colleague who now works for a gaming company told me that their stories were not far off being ‘build a game’. I’m not sure why this is. I think maybe people know that a story should describe a discrete piece of functionality, and deliver value to a user, but they come up with things in terms of a traditional end-to-end use case, like ‘user buys a book’.
Now, ‘user buys a book’ is a huge epic of a story. On any bookstore site you’ve got the page which displays information about the book, you’ve got several screens of complex shopping cart functionality, you’ve got email receipts, hooks into the backoffice, etc. Starting at the beginning, your first story might be ‘Show book information’. Suppose your UI prototype is this screenshot from Amazon:
There’s an awful lot going on just on that page. What’s the most basic information you could include in ‘Show Book Information’? How about the title, author, and perhaps the front cover image? That will do for our first story. I would actually photoshop my screenshot and stick it to the front of the story card:
While my acceptance criteria would look like this:
| Action | Expected Result | |
|---|---|---|
| 1 | Go directly to the URL of a book, e.g. /books/book?id=1234 | See a page which shows the following information about the book: the title; the price; the cover image |
There’s a number of things to note here. I started the acceptance script with ‘go directly to the url..’. That’s because at this early stage of the project I’m presuming there’s no way to search or browse to that page. I didn’t include price in this basic initial set of information. You might think that’s fairly fundamental, but my guess would be that the price is stored in a more complex piece of the backend that we aren’t talking to yet. I have included the cover image, assuming that is straightforward. These are all things I would know by talking to my developers. Adding the price would likely be my next story:
One temptation to avoid is putting dead links and buttons to things you haven’t developed yet. It would be no work to add the button which says ‘add to shopping basket’ at this stage – but it wouldn’t go anywhere. Doing this violates the principle of always having shippable software. Suppose we decide we have enough to beta the site as a kind of catalogue, without purchasing facilities – in that case we don’t want buttons to non-existent ecommerce sequences to appear. That may seem pretty obvious – but it’s quite easy to imagine buttons like ‘Tell A Friend’ or ‘Add to Wish List’ appearing on a live release before anyone remembers those features didn’t make the cut. I’d add the button when I do the story ‘Add book to Shopping Cart’:
| Action | Expected Result | |
|---|---|---|
| 1 | Go directly to the URL of a book, e.g. /books/book?id=1234 | See a page which shows the information about the book as before. Now see a button marked ‘Add to shopping basket’ |
| 2 | Hit the button to add to basket. | Advance to the next screen, showing… |
I think a lot of people might say here that I’m going too far, and these stories are too small. For a lot of situations they might be, I used to produce stories this size when working with teams whose iterations were only 1 week long. But I think the basic principle is sound. You can almost always break things down – If there’s a tangible result and you can establish good acceptance criteria then it can be a story.
Posted on November 22, 2008
0