User stories
Stories are the building blocks of communication between developers and those who use their work.
What are agile user stories?
A user story is an informal, general explanation of a software feature written from the perspective of the end-user. Its purpose is to articulate how a software feature will provide value to the customer.
User stories:
Are easy for anyone to understand
Represent bite-sized deliverables that can fit in sprints, whereas not all full features can.
Help the team focus on real people, rather than abstract features
Build momentum by giving development teams a feeling of progress
The 3 C’s of User Stories
Card – a written description of the story used for planning and estimation.
Conversation – Discuss your ideas with others. Let them ask lots of questions. Work together to come up with ideal solutions. The goal is to build a shared understanding.
Confirmation – Work towards agreement on what to build. Record that agreement as a set of confirmation tests.
Types of User Stories
We can classify user stories into functional and technical types:
Functional – Normally, a user story is written based on the functional aspects of the application software, while focusing on the user and the value of the functionality provided to the user. Functional stories concentrate on the product features which the customer will be testing at the end of an iteration based on the acceptance criteria defined for the story.
Technical – Technical stories are written to be able to support the functional stories. Technical stories can be classified as
Infrastructure stories – any infrastructure addition/modification that may be required to support the functional story
Refactoring – this type of story is written to maintain the code and address technical debts. This can be used for designing and automation needs as well
Spikes – stories that require research on architecture and design which may in turn help achieve the functional need of the customer.
Why create user stories?
For development teams new to agile, user stories sometimes seem like an added step. Why not just break the big project (the epic) into a series of steps and get on with it? But stories give the team important context and associate tasks with the value those tasks bring.
User stories serve a number of key benefits:
Stories keep the focus on the user. A To-Do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
Stories create momentum. With each passing story, the development team enjoys a small challenge and a small win, driving momentum.
INVEST Guidelines
The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story.
Independent – Each User Story should represent a distinct and independent set of business values such that, were it released on its own, it would deliver incremental value over the previous state.
Negotiable – While the end-goal may be clearly described, the methods by which that goal is achieved should be negotiable – between the Product Owner and the Development Team, the Product Owner and the Customer, or any other involved stakeholders – so as to prevent unrealistic constraints on the feature or functionality.
Valuable – The business value of any User Story should be readily recognizable by reading the story, and each story should represent some sort of value to a specific user type.
Estimable – We must have enough information that we can properly size a story so that we may properly plan and commit to our work. (But no more!)
Small – User Stories should be small enough that they are able to be completed within a sprint.
Testable – All members of the team need a clear and precise way to verify whether or not a User Story has been completed.
What Does a User Story Look Like?
Most product teams use a similar user story template, typically just a sentence or two written according to the following formula:
As a [description of user], I want [functionality] so that [benefit].
User story examples
UseCase: when we build a website that has two types of users ‒ logged-in users and guests ‒ we’re likely to write the following acceptance criteria for a user story that defines the sign-in feature for a logged-out user:
As a logged-out user
I want to be able to sign in to a website
So that I can find access my personal profile
Scenario: System user signs in with valid credentials
“Given I’m a logged-out system user
and I’m on the Sign-In page
When I fill in the “Username” and “Password” fields with my authentication credentials
and I click the Sign-In button
Then the system signs me in”
The Given/When/Then template helps you reduce the time spent on writing test cases since you describe the system’s behavior upfront. We prefer writing acceptance criteria with the first-person “I” since it helps us talk from a user’s perspective and keep a user’s needs in mind.
How Do You Write a User Story?
Consider the following when writing user stories:
Definition of “Done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For Whom? If there are multiple end-users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
Here’s a simple, six-step process for crafting user stories:
Step 1: Decide what “done” will look like.
In most cases, the user story describes an end-state: when the user is able to complete the task or achieve the goal described. You need to have this end-state in mind when you write yours, so the rest of your team knows when they can mark the development work done. (Learn more about the definition of done.)
Step 2: Document tasks and subtasks.
Although your actual user story will include only the standard statement we described above — “As a [persona], I want [feature] so that [reason]” — you will also need to document the details required to complete the development work described in the story. That means outlining tasks and subtasks and assigning them to the right people.
Step 3: Determine your user personas.
Who is served in this story? Which type of user or customer? You need to document this upfront. If you have several different users in mind, you might want to break this into more than one user story. This way your team can stay laser-focused on helping a specific persona achieve a specific objective for each story.
Step 4: Create stories as ordered steps.
The concept of user story mapping suggests that you can think of your entire product as a series of tasks or jobs the product helps your users complete. With that in mind, if you’re trying to structure work on a larger process or a more comprehensive set of product functionality, write each self-contained step as a story.
Step 5: Seek user feedback.
To improve your chances of allocating resources to development work that will resonate with your market, talk to users and customers about their priorities, and learn what more they want from your products. Only after gathering and analyzing this feedback should you begin crafting user stories.
Step 6: Draft stories that can be completed in one sprint.
User stories that take longer than a single sprint (typically two weeks) should be broken into smaller stories. This way, your team gets a sense of completion in each sprint, because they’re able to complete some new functionality each time. It also allows your team to push out new functionality to the market more frequently.
