User Story Basics
You probably landed here because someone told you to write a user story or becausee your user story isn’t quite working for your engineering team. As I explained when I shared my favorite User Stories Template, Users Stories are a key PM artifact, but they always need to be adjusted to your team.
No matter what format you use, adjust the stories to your team’s needs until you find the right approach for your team.
Getting Started
It starts with this simple sentence:
As a ______, I want ______, so that I can _______.
A more relaxed phrasing is often just as effective at communicating the overall intent of a user story but for newbies, we will stick to the fundamentals.
Done well, 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
Examples
As a
Who - wants to accomplish something
What - they want to accomplish
Why - they want to accomplish that thing
In the most basic form:
As a bank customer
I want to withdraw money from an ATM
So that I’m not constrained by opening hours or lines at the teller’s
Other examples:
As a social person, I want to invite my friends, so we can enjoy this service together.
As an organized person, I want to organize my work, so I can feel more in control.
As a manager, I want to be able to understand my colleague’s progress, so I can better report our successes and failures.
Why are User Stories Important:
Stories keep the focus on the user. Stories elevate the discussion above to-do lists.
Stories enable collaboration. With stories written rather than just a list of requirements, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Again, stories over lists encourage the team to think critically and creatively about how to best solve for an end goal.
Stories create momentum. Breaking the problem at hand down to stories helps to make the problem easier to tackle in pieces.
How to Write:
Definition of “done” — The story is generally “done” when the user can complete the outlined task.
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 — Stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
Here is a list of templates from around the internet:
Why I like it: Several different formats that are all simple and straightforward.
Why I like it: Covers categories, mapping, and role-based. Also shows how to move this info to Kanban.
Why I like it: Covers fundamental definition and origin story.
Why I like it: Covers the basics and talks about making it work in Jira, which many folks use after writing stories.
Why don’t love it: Talks about names rather than role descriptions. For most engineers, remembering some marketing name isn’t helpful
Why I like it: Nice quick and simple format. Focus on Acceptance Criteria, which is often the biggest concern with engineers “So how will I know you have what you need.”
Why don’t love it: Expect solutions to be complete in one sprint, I don’t necessarily agree with that one.
Photo by Aaron Burden on Unsplash
