6/8 - Agile User Stories
A user story is an informal, general explanation of a software feature written from the perspective of the end-user or customer.
Hello Product Managers, This week’s newsletter is brought to you by UserLeap
UserLeap enables product teams to quickly and easily understand their audience, improve their product, build their roadmap, and solve complex business problems through a combination of contextual micro surveys, AI-based text analysis, and 75+ research templates. Learn more
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 (Card, Conversation, Confirmation) 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.
How to write user stories
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.
How to Write Good User Story with 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.
User Story Example :
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.
Here are a few tips that’ll help you write great acceptance criteria:
Keep your criteria well-defined so any member of the project team understands the idea you’re trying to convey.
Keep the criteria realistic and achievable. Define the minimum piece of functionality you’re able to deliver and stick to it. On the other hand, don’t try to describe every detail since you risk cluttering up your backlog and getting buried under many small tasks.
Coordinate with all the stakeholders so your acceptance criteria are based on consensus.
Create measurable criteria that allow you to adequately estimate development time so you’re able to stay within budget and time constraints.
Consider providing checklists that enable you to see what user stories are covered with acceptance criteria.
You might also like :
User Stories Playbook (Pre-Order @50% off)
This is for you if:
You are a new product manager
You don't know how or where to start
You've started working on the product role but still feel lost about writing stories
You're none of the above but you know someone who is. Gift them!
Thank you for your support, Product Mindset Team.