An Introduction To Agile User Stories

Any software development should be driven by a set of requirements for the system. Over the years there have been many approaches to gathering and documenting requirements, many of which can be quite daunting. Agile software methods make the process more accessible by focussing on user stories.

A user story begins as a sentence describing a feature that we want to achieve in the product. For instance, let’s imagine that we are building a system for online shopping; we can describe how we want shopping to work in a set of stories, covering things such as finding products, adding them to a basket, and then proceeding to checkout. One such story concerns the shopping basket, and our desire to let the purchaser see it. So we can write this story as:

“As an online shopper, I want to view the contents of my basket so that I can verify its contents before purchasing them”

Note, this sentence description is sometimes call a “card” since it is often written on a card or post-it note, and stuck on the wall, along with all the other cards representing stories we’ve thought of.

The user story is structured to show who wants it (the shopper), what they want (to see their basket) and why (to verify its contents). It is also written in plain English, avoiding technical jargon.

Using this technique, we can rapidly develop a set of stories that describe how the system should behave, from the user’s viewpoint. There may be several different types of user; for instance, browser, shopper, marketer, content editor, systems administrator, etc., and we can write stories for all of them. This is usually done collaboratively, with a bunch of people writing out cards, grouping them together and reviewing. After a short period we should have a broad idea of what our system should do, encapsulated in a set of user stories, which we call the Product Backlog.

Compared to traditional methods of capturing requirements (e.g. use cases), this may see very imprecise. And it is – we are looking for breadth rather than detail at this stage.

In Scrum and other agile methods, a person called the Product Owner is ultimately responsible for the stories and the product backlog. The Product Owner selects a few stories of interest (usually because they will be implemented next), and then the conversations can proceed. In our shopping basket story, we could describe what the shopping basket should look like on the screen; we could sketch a web page; we would clarify the terminology and answer any questions that the development team might pose concerning the basket. A member of the team should capture any output as notes, sketches, photographs etc., and attach them to the story.

The adjoining sketch shows conceptually what the web page could look like, without any fancy graphic design.

Finally, we should summarise our understanding as a set of acceptance criteria, or confirmation.

For our shopping basket, these could be:-

1. The shopping basket should be displayed on the screen (e.g. as a web page)
2. There should be one line for each item in the basket
3. Each line should show the item (with product ID, name and a clickable link to its product page) and its cost
4. The total cost of all items in the basket should be shown
5. There should be a button for “Continue shopping” which returns you to the previous page
6. There should be a button for “Checkout” which takes you to the checkout page.

The acceptance criteria provide a concise summary of what the story should achieve. Well-written acceptance criteria are understandable by all parties and remove any ambiguity.
During this process, other considerations may strike us. For instance, what does the basket look like if there are no items in it? Or what if we want to remove items from the basket? As these thoughts occur, we should decide whether they are sufficiently trivial to be added to the current story (and to the acceptance criteria), or whether to capture them in separate stories and add them to the product backlog for later consideration. Finally, we have a fully specified story, ready for implementation.

One other thought: As we develop stories, we also start to use a set of terms which help to describe the domain – e.g. “basket”, “product”, “checkout”. It is very useful to capture these and put them in a glossary of terms, with their definitions as we go along. This will help to reduce confusion later on, by encouraging all participants to use the same language.

So in summary:-

1. Define stories incrementally – don’t try and detail all the requirements at the start
2. Use language and terminology that your users and stakeholders understand
3. The user story is just the start of a conversation
4. Develop a glossary of terms to capture the vocabulary being used
5. A story is ready for implementation when it has clear and unambiguous acceptance criteria
6. Stories may be split, or alternatively combined with other stories, to keep them manageable

Follow these simple rules and you’ll be well set up for the next stage – design.