A User Story is a common method of turning traditional user requirements into a feature for an Agile team to work on. It is written from the end users perspective and describes the value of the work to the business along with the acceptance criteria that satisfies the story.

User stories were first introduced in Extreme Programming back in 1998 and have been through numerous iterations or styles since. The most common format and one I use most often is…

As a [user]


I want to [action]


So that [business benefit]

Personally I think the last part (the so that…) is the most important part of a user story. The so that describes why the story is being completed and when completed correctly I find it helps bridge the gap between scrum team member and the business. It helps the developer get an understanding of why the feature or story they are working on is valuable to the business or product.

Acceptance Criteria

On the back of a user story you also have the acceptance criteria for the story. These are used by developers, QA’s and PO to assess whether the story is complete or not. I’ve seen stories written without acceptance criteria and it’s no surprise that these stories are the ones that are constantly re-worked (usually after they are put into live) or take the longest to go through the QA process.

The acceptance criteria should avoid being hugely technical and should describe the front of the card in greater detail. However, all user stories are a place holder for a conversation and should always follow the I.N.V.E.S.T (Independent, Negotiable, Valuable ,Estimable, Scalable ,Testable) mantra. Far too many “projects” contain stories that do not adhere to this and these stories are the ones that tend to take considerable effort for the team to discuss and breakdown in backlog refinement or sprint planning sessions which ultimately takes the team away from doing what they do best.

User Story Smells

Below are a list of items that suggests a user story isn’t in its best shape

  • Can it fit on a card? A physical record card or post-it is a great way to ensure a story is small enough. If the story cannot fit onto a card then it’s either too big or contains way to much detail (and will require breaking down). This is one downfall of electronic tools in that they allow a user a free text box to enter detail about a story.
  • If it does fit on a card, is it readable? I’ve known stories to be written such small handwriting that it becomes illegible only for the writer of the story to say “it fits on the card”. Mike Cohn’s excellent book User Stories Applied suggests reducing the size of the card to really make the user think about their story and its content
  • Does the acceptance criteria repeat the front of the card? If your acceptance criteria essentially just repeats the front of the card then it suggests the acceptance criteria hasn’t been thought of enough.
  • You can’t think of acceptance criteria – this suggests the story isn’t valuable to the business or product. If someone cannot write a very short concise user story about a feature then in my experience has lead to the requirement not being well thought through or will provide very little benefit once delivered.
  • The user is very generic – I’ve seen user stories written along the lines of “as a business”. Statements like this suggest the writer of the story doesn’t know their product, stakeholders or customers well enough. Stories should always have a real user of the product associated to it. Statements such as “As a Business” are so vague and I’ve found that vague users like this hide more detailed requirements that are actually needed for different types of customers or end users.