User Stories

Agile Manifesto
Agile Dictionary
Delivery Plan
Extreme Programming
UX Design


This lecture focuses on creating user-stories

The Big Picture


A user-story is part of a hierarchy, it sits just above the acceptance criteria's and beneath an epic. So why do we start here? This is probably because this is the lowest part where we can prioritise and derive value. However, it would be really difficult to make sense of the evolving detail, hence the hierarchy allows the structure we need to understand where we are and where we want to get to.

At epic level - we can group the user-stories; generally if a user-story cannot be completed in a single sprint it is packaged as an epic. A feature is more specific in a set of functionality that delivers business value. Grouping epics/user-story under a feature provides clarity in the functionality to be created and helps to understand the dependency of any other features.

The theme is the focus or the goal to be achieved. The theme can be driven by product iteration(s) or the entire length of the product development.


User story

A User-story is a conversation, it is structured in a very simple natural language and has a set structure. It is customer driven, where the outcome and impact is understood as part of a conversation between two people.

The common language is very similar to Gherkin and is often written on Post-it notes or card.

3 C's Card, Conversation and Confirmation are the components for a user-story. It is imperative that the process starts and ends with an conversation and there is an confirmation or agreement on the outcome. User-stories have traditionally been written by Business Analysts - but can be written by customers, stakeholders, developers almost anyone.

From an Agile perspective user-stories need to be concise and light in order to develop them iteratively. The emerging details appear during the Sprint, So high level or start-up stories are written at high level. This is too ensure we have the flexibility in design and approach. All the detail will be revealed at the right time.

There are two parts of a User-story on a card or post-it, the front the actual story and the back of the user-story is the Acceptance Criteria

Acceptance Criteria

An acceptance criteria is used to validates a user-story ensuring the actual behaviour of the feature is the expected behaviour from the perspective of the customer. A well tested acceptance criteria improves the quality of the feature. In Agile a Behavioural Driven Development (BDD) approach is used in the form of scenario based GIVEN - WHEN - THEN format. The format of a acceptance criteria is shown below:


User-Story Structure


A user-story should be Independent. It needs to be stand-alone and have not be dependent on other stories, normally user-stories are broken down further in order to get into more detail and lower the estimate on the delvery. However, grouping similar dependent user-stories into a single user story is more practical.


User-story is negotiable, it is not set agreed terms as the detail for the feature is emerging and can potentially be changed. The Agile principles states

"...Welcoming changing requirements, even late in development. Agile processes harness change for the customers competitive advantage..."


User-stories should be created if they have either business or economic value. They are not a wish-list but a clear and concise representation of the business or technical needs of the feature. They should be written in simple language this would result in less ambiguity in its representation.


Stories need to have clarity in its detail. It should be simple to understand so simple to estimate. Using common language is important to reduce the complexity in the detail. User-stories should not contain detailed description, this can be done at a higher epic level.




The INVEST model highlights the structure for a good user-story describing the detail of what components should be included.

You are not authorised to use this material without the written permission of the author. The contents of this material must not be distributed or used for any teaching purposes. Failure to comply may result in criminal prosecution. Go to Previous Page Go to Next Page Contact Vas Rabani for any comments on the website or queries