User Stories at a Glance
-
- represent the user role, functional requirement, and their motivation for desiring certain functionality.
- ensure the benefits for the user remain at the centre of the development process.
- foster collaboration, creativity, pace, and a continuous sense of achievement.
- should be Independent, Negotiable, Valuable, Estimable, Small, and Testable.
- can be mastered by taking part in one of QA’s expert-led courses in Agile.
What is a User Story?
A User Story is a short, simple description of a software feature expressed from the perspective of a product’s end user.
The idea behind User Stories is to place the end-user experience at the centre of the development process. To do this, User Stories highlight the role or position of the user, then detail the functionality they want and why they want it.
To incorporate these three pieces of information, User Stories typically follow a simple template:
As a <type of user>, I want <goal>, so that <reason>
A key feature of User Stories is that they represent the smallest possible piece of work, i.e., tasks that can’t be broken down or divided any further. Plus, each User Story relates to a single functionality of a given product or service.
This means that User Stories apply well to an agile environment, as they are concise, finite tasks that can be completed within a given iteration, e.g., a sprint.
User Stories in Agile
User Stories, as their name suggests, centre around the requirements and experience of users. As a result, they incorporate the first principle of the Agile Manifesto: 1
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
User Stories are highly beneficial for teams using agile frameworks such as Scrum and Kanban. User Stories are added to a team’s backlog and are pulled into the iterative workflow. For example, in Scrum User Stories are pulled from the backlog into sprints, and in Kanban User Stories are moved through the workflow according to a team’s work-in-progress limits.
Estimation
User Stories help teams to plan the upcoming workflow. The process of User Story creation involves determining the time each task will take. The estimated time is then represented using simple, easy to understand units such as Story Points or T-Shirt sizes.
In breaking larger projects down into smaller, more manageable segments, User Stories allow teams to increase their agility, flexibility, and ability to work iteratively. Plus, given that User Stories highlight the wants of the end users, teams can more effectively prioritise by focusing first on the tasks that will bring the greatest impact to the end user.
When teams don’t have enough information to be able to assign a time estimate to a User Story, it’s known as a Spike Story. Spike Stories may require teams to carry out research to determine timescale estimates, or they may need to be broken down into smaller, estimable tasks.
Planning poker
To help teams estimate a rough timeframe to attach to their User Stories, teams often incorporate planning poker into their development process. Planning poker is card game that encourages collaboration and ensures the team is in agreement when it comes to timescales.
In planning poker, each team member is given a deck of cards displaying a range of the estimation units used by the team e.g., Story Points. A User Story is then read out to the team and discussed, and each team member holds up a card showing their estimate of how long it will take. The responses are then briefly discussed and an agreement is reached.
What makes a good User Story?
User Stories evolve over time from vague, nebulous concepts into specific, well-articulated needs. A good way to assess whether a User Story is well defined is to use Bill Wake's INVEST mnemonic.
The INVEST mnemonic encourages teams to ask the right questions of their User Stories or Product Backlog Items (PBIs).
Your User Stories, as the table below shows, should be: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
|
Independent |
Independent of other User Stories, meaning they can be developed in any order |
|
Negotiable |
Facilitate open conversation within the development team: changes to the User Story can be discussed and implemented |
|
Valuable |
Bring value to user/stakeholder, adding overall value to the product |
|
Estimable |
Able to be estimated using the sizing criteria discussed, e.g., T-Shirt sizing or Story Points, allowing prioritisation and scheduling |
|
Small |
Must be manageable enough to be developed in a single iteration, and not so detailed that ongoing conversation is redundant |
|
Testable |
Should only be considered done once it meets agreed acceptance criteria that can be tested and validated |
If your User Stories meet the INVEST criteria, then your team is set for success in its workflow management.
User Story benefits:
User Stories offer a great number of benefits to development teams:
- Stories ensure the team remains focused on the benefits for the user and the business value, ultimately developing a better product that is not only well built technically, but also brings real value to real users.
- User Stories encourage and facilitate collaboration. With the focus on a team-wide discussion rather than on lengthy, written explanations of requirements, the team is freed up to collaborate, drawing on one another’s strengths and expertise.
- User Stories foster creativity. The team are encouraged to critically and creatively consider how to achieve the end goal.
- Stories create momentum. The development team complete small, manageable tasks consistently as the User Stories pass through the workflow, offering a regular sense of achievement and creating pace.
Writing User Stories
Writing User Stories is a collaborative process for the whole development team to get involved with, if possible. Whilst the Product Owner must ensure there’s a backlog of User Stories, as well as ensure they meet the INVEST criteria, they aren’t solely responsible for creating them. Generally, User Stories are created during a team meeting at the beginning of a project, although they can be added to the backlog at any time.
How to write a User Story?
User Stories consist of:
- Written descriptions following the ‘as a <type of user>, I want <goal>, so that <reason>’ template, which are used for planning and as reminders
- Conversations between teams that serve to flesh out the details of the story
- Tests that document details and can be used to determine when a story is complete
To reflect this idea, software developer Ron Jeffries came up with the 3Cs: Card, Conversation, and Confirmation:
Card
User Stories are written on cards. The card does not contain all the information that makes up the requirement. Instead, the card has just enough text to identify the requirement and to remind everyone what the story is. The card used in planning: notes are written on it, reflecting priority and cost.
Conversation
The requirement itself is communicated from customer to development team through conversation: an exchange of thoughts, opinions, and feelings. This conversation takes place over time, particularly when the story is estimated and again at the iteration planning meeting when the story is scheduled for implementation.
Confirmation
Once the improvement and action required has been defined, there needs to be a clear way to determine whether or not it’s complete. This component is the acceptance test. 2
Before writing your User Stories, ask yourself the following questions and discuss them with your team:
- What is your Definition of Done? Your user needs to be able to complete the action defined in your User Story. This needs to be clear and able to be validated.
- Who is the user in your User Story? Spending time creating detailed, specific user personas will help you create your User Stories: an insight into users’ wants and needs will help you develop a better, more user-friendly product.
- Can the task be broken down any further? As mentioned, each User Story should refer to a finite, manageable task, relating to a single piece of functionality. If your User Stories are too big, they put the agility of your team at risk.
- Have you had feedback from your users? Without a grasp on the experience of users, you won’t be able to tailor your development to deliver continuous value for them.
User Story examples
The User Story template you’ve already seen is a great way to ensure you capture all the information your development team needs.
Let’s see what this template looks like on an example User Story card.
Now let’s see how this might apply to a real-life business scenario.
An example User Story:
With acceptance criteria on the back of the card:
This template can be applied to a wide range of environments to ensure each step of the development process brings value to end users. Next time you’re looking to develop the functionality of your product, try using this template to keep the user experience in mind.
Learn more about User Stories
If you’d like to learn more about User Stories and how they function within Agile workflows, or you’re thinking about adopting Agile principles within your team, QA offers a number of agile lean courses which will help you, and can help you become Agile certified.