In a more ideal world than what we have now, we could understand each other fully with few exchanged words and without giving proper context to what we are talking about. In our world, we need to give a basic idea on what we're trying to do, then later on expand on them with more thorough requirements.
In software development, user stories help shift the focus from writing about every single requirement from the start to a discussion about the idea. This is normally a few sentences on the desired functionality.
This post will discuss the following on user stories:
- What is the definition?
- Why are they used?
- When are they written
- How to write user stories
Defining User stories
A high-level user or business requirement commonly used in Agile software development, typically consisting of one sentence in the everyday or business language capturing what functionality a user needs and the reason behind this, any non-functional criteria, and also includes acceptance criteria. - ISQTB
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective. Atlassian
Why are they used?
- Maintain focus on the user - With more understanding of what the user wants, the team is more focused on how to solve the users problems
- Collaboration - When we have a goal, we set objectives on how to go about achieving that goal. The only way to achieve these objectives in good time is through joint effort
- Creative Solutions - There is never a one way solution on how to go about solving a problem. Collaboration allows the discussion of different solutions and think about which solution is best to achieve the goal.
Who writes User Stories and when are they written?
The first draft is normally written by the product owner. These stories are then reviewed by the development team and other internal business stakeholders to give different viewpoints. Most of the time, they are written as epics, then they are broken down into stories that best serve each functionality or work to be done.
User stories are written before it becomes part of the sprint and certainly when it's added to the backlog. Usually, the developers are briefed on a future feature a few sprints ahead, with discussions that shape up the requirements.
User stories should be agreed upon by the team and that it can be understood by anyone.
How to write user stories
Before writing down user stories, here are a few things to consider:
- Define "Done" - What does done mean in regards to the feature you are about to release? It normally means that the user can do what they want to do
- User Personas - Who is going to be using this feature? How is each user going to benefit with this feature?
- User Journey - What parts of your system will the feature be in? How are they going to get there?
|As a < type of user >, I want < some goal > so that < some reason >.|
- As a [type of user]: Who are we building this feature for? This could be for client X, this could be for client Y
- I want to [some goal]: What is it that Client X and Y are trying to achieve?
- So that [some reason]: How will this feature benefit the client? What problem are we solving?
Sample business case 1: Update access levels for users
User Story: As an admin, I want to go to the Users page and update the access levels of my team members so that my team has access only to sections that they need
Sample business case 2: Search bar to find items
User Story: As a library member, I want to search for my books using a search bar, so that I can find my books easier