What Makes A Good User Story

Writing User Stories
Team Planning

Good user stories are at the heart of team workflows and facilitate a clear way forward by focusing on simple and clear business value in line with business goals. These user stories most often provided through the Product Owner of the team. As defined in XP, the 3 critical aspects of a User Story are Card, Conversation and Confirmation. Very briefly, the Card is the starting point which allows everyone to understand what the goal of the story is. The Conversation happens between the team, customers, and stakeholders which surface good questions to flush out the expectations and reasoning to get a better understanding of the requirement. The Confirmation is the agreement or the acceptance criteria created in oder to meet the needs defined form the Conversation. Despite appearing simplistic, writing user stories can be quite challenging and take some practice. Over time writing user stories generally improve as domain knowledge and relationships develop.  This post shares just some very basic techniques to help you on your way.

To start off, Roman Pichler provides some useful insights through 10 Tips For Writing Good User Stories.

In line with the tips defined above, some of the key points I like to embrace with teams tend to focus on the following  :

  • A good acronym to refer to when creating user stories is to consider INVEST User stories should be Independent, Negotiable, Valuable, Estimable, Small, Testable
  • The popular story format “As a (user role), I want (function) So that (benefit)” helps you get the focus right. You don’t always need to conform to this structure, but having a simple way of identifying the user, the action and the value delivered helps focus the conversation and encourages value focused questioning.
  • A story is not a specification, and it does not replace a dialogue.
  • Story writing is teamwork. Although the user story might have most of the requirements in place, it should not be considered complete specification. To get a user story into a ready state requires team conversations, feedback, opinions and questions to be sure everyone in the team understands what is being asked and understands the value. User stories are not items of work to assume and assign to individuals.
  • Use language that is easy to understand and focuses on the customers value. Avoid using technical jargon which abstracts information and makes it difficult for the whole team to understand. Think if anyone walking past the board picked up the story, would they understand what’s being delivered?
  • Don’t forget the acceptance criteria. To meet the user story goal, conditions of acceptance provides clarity and depth. This emerges via team conversation.
  • Keep your stories visible. Visible stories not only radiate progress and status, but they promote conversation and valuable feedback which can increase a stories value impact.
  • User stories have to have a clear business value, which is driven by the Product Owner to reach the business goals. Clear business value is the currency to negotiate and present priority.
  • User Stories are created by the team through a team conversation. They should not be created and pushed onto others, which breaks the conversational model and reduces the impact of the solution for many reasons.
  • Defining different classes of User Stories such as Bugs, Spikes or Chores are still subject to prioritisation by value through the product owner and team. Different classifications should not be used as back doors to get personal preferences on the board which by-pass the teams planning and conversational practice.

Putting this into practice

When looking for a way to structure Acceptance Criteria, ‘Gherkin’ style formatting which has emerged from BDD can provide a simple solution. If you are using BDD tools such as Cucumber, you will already know how valuable this practice is to Agile teams. This not only provides the ability to functionally test features, but tests are easy to read using a language that everyone understands, which is very powerful in getting people working together. This also allows the practice of living documentation which grows with the development of each of feature. If you’re not using BDD, I would highly recommend looking into it, but this is a topic for another blog post.

You don’t have to have Cucumber in place to format user stories in Gherkin format, you could start by using this language on the User Story for acceptance criteria. This format creates a simple common language which enables anyone to look at a card and understand it in it’s simplest terms. Let’s take a look at some simple examples :

Basic Structure

As A (role)

I Want To (do something)

So That (benefit)


In order to (business value)

As a (user)

I want to (gain outcome)

Acceptance Criteria :

Given (the starting point/initial state)

When (action)

Then (outcome)


Basic User Story Example

Lets say we want to search for a book that is listed in the store.

As A teacher

I Want To search for a book using the title

So That I can check the price and availability


Given that I am on the home screen (known state)

When I enter a book title into the search field for a book which is in stock

And press search (action)

Then I should see a list of all matched books by title

And this list should be presented in alphabetical order in Ascending order

And next to each result I should see the price and stock level (outcome)


Given that I am on the home screen

When I enter a book title into the search field for a book which is isn’t in stock

And press search

Then I should see a message indicating the book is not in stock

Remember this is a team conversation and more criteria will emerge which could also alter the main part of the story. When breaking up the acceptance criteria, you can also discover that the story can be broken into more stories. I tend to favour the team choosing to split stories into the preferred granularity, but encourage smaller stories to keep the flow. Using Gherkin acceptance criteria, you can split stories where the acceptance splits occur, for instance in the above, the separate ‘Given’ statements could be stories or in some cases the ‘And’.


Some examples of User Stories which require more work

Example 1 :

As A User

I Want To read the sports news

The  term “User” is ambiguous and there is no clear value identified which would usually be captured by the “So That”. The “Sports News” is not clear and appears to be very high level, this could be broken down into many levels. What sports news? Is this a registered football fan? Is this the most recent sports news? and so on…

Example 2 :

As A First Year Student

I Want To submit my english assignment from within my english language class

So That I can meet my homework deadline


Given that I am a user

When I submit my coursework

Then it should submit to the system

The acceptance criteria doesn’t present a clear path to validate or meet the story conditions. What steps need to be achieved to satisfy the story ? Could someone pick this up and understand what needs to be implemented or has the ability to follow the steps to test it? The Acceptance criteria needs to be broken down much further. This story could at an epic level and broken down much further and into many stories.


  1. Just a small but, nevertheless, important point… One should always avoid including references to UI widgets in user stories (and use cases, if used).

    For example, “When I enter a book title into the search field for a book which is in stock And press search (action)” is a description of the assumed UI, which is a design artefact, not a requirement (ie describes how not what).

    The biggest problem I see (repeatedly) with user stories and uses cases is that the author imagines a UI and then describes it, which makes them overly complex and brittle. The following version assumes no UI design (I have also corrected the error that infers a full title is supplied but produces a list of options when there can be none, and even this is not really explicit enough…)

    Given that I am ready to do an inventory search

    When I supply a partial title of a book that is in stock

    Then I should see a list of all books in stock with that partial title

    And this list should be presented in Ascending alphabetical order

    And associated with each result the price and stock level should be available to view

    Alan Jackson

    • I generally agree with the point that describing the UI concept can lead to limitations at the design phase – Let’s say that a UX specialist may design a better, completely different concept.
      However, some situations require strict preservation of the UI, which make the UI specification really part of the requirements.

  2. The Gherkin Based behaviours don’t have Scenario headings… I would say these are Test cases not acceptance criteria, This kind of out line is something I would expect to happen after first refining the Story In question. I think you guys are missing a step.

    Story > Acceptance criteria/Scenario headings > Gherkin behaviours

    take this example for above:

    Given that I am on the home screen (known state)
    When I enter a book title into the search field for a book which is in stock
    And press search (action)
    Then I should see a list of all matched books by title
    And this list should be presented in alphabetical order in Ascending order
    And next to each result I should see the price and stock level (outcome)

    This isn’t one acceptance criteria, many things are being asserted on the back of that initial behavior

    Acceptance Criteria should show the what not the how like this:

    * Search by title returns a list of books
    * The results list is in Ascending Order
    * The results list shows the stock level of each returned title

    One of the biggest problems with that story is it takes a while to write, in a meeting full of people it’s not a practical exercise to undertake. If you are ever going to write gherkin scenarios please start with the scenario heading, That will explain the intent behind the behaviour, then write the scenario to explain how to demonstrate that behaviour

    • Hi Peter, Thanks for providing this feedback and comments. I completely agree with your additions and the Gherkin based steps are steps which would benefit from the scenario headings as you have added for context and meaning. However, although the example above whcih are Gherkin Steps could be seen as test case, but could also be used to partially inform the accepetance criteria. I’ve personally seen Gherkin test cases be used and add value as a detailed form of accepetance criteria (depending on the complexity and context of the change of course) which is sometimes where the line can blur in my opinion. Sometimes the accepetance criteria isn’t enough to agree whether the goals have been met and the level down can provide that. I do agree though striving for a clear structure of Story > Acceptance criteria/Scenario headings > Gherkin behaviours is the way to go, but being flexible to allow engagement to oversee the steps (where appropriate) in addition to the higher level accepetance criteria would be encouraged.

      “If you are ever going to write gherkin scenarios please start with the scenario heading, That will explain the intent behind the behaviour, then write the scenario to explain how to demonstrate that behaviour” – This is a very valid point as well, so thanks for calling that out!


Leave a Reply

Your email address will not be published.