Every feature the Sean Dinwiddie’s Webmastery team builds begins as a user story: who it serves, what they need to do and why, in words the owner reads before work starts.
A user story keeps the needs, wants and expectations of the people you serve in front of everyone who builds for them, so the solution fits your clients, your team and the job.
What a user story is
A user story describes one feature from the side of the person who uses it, in a sentence anyone on the job can read. Stories come from Extreme Programming and spread with agile methods, which prize collaboration, customer feedback and small, incremental changes.
The classic shape, from Rachel Davies’ team at Connextra:
“As a [type of user], I want [an action] so that [benefit/value].”
For example:
“As a customer, I want to see where my order is, so that I know when it will arrive.”
Later in the course, what happens in a story becomes an event in the code, named for what happened: behind the story above, that would be orderShipped, and the cart in From scenario to slice names its event itemAdded; the lecture Redux Toolkit and Functional Programming shows why an event beats a setter.
Why they matter
- Client-centered: User stories keep the focus on the people who use the software: every feature in the written scope answers a need one of them has.
- Collaboration: Everyone on the job reads the work from the user’s side, so the owner and the webmasters are always talking about the same thing.
- Prioritization: Stories line up. The most critical need goes first, and the rest wait their turn.
- Flexibility: Stories bend as you learn: add one, change one or drop one as feedback comes in. A story that arrives after the written scope is signed gets its own quote, approved before it starts.
In the team’s work
Sean Dinwiddie’s Webmastery writes the scope of every feature as user stories, so the owner reads the job in plain terms before it starts.
Written that way, stories help you:
- See the job from your client’s side, in their words.
- Put features in the order users need them.
- Talk with your development team about the same thing.
- Change course as the project teaches you more.
The writing is the easy part; the understanding behind it is the craft. The lessons that follow show how, from the first conversation with a user to the story the owner reads in the written scope.
Next steps
The next lesson, on behavior-driven development (BDD), turns a story’s acceptance criteria into scenarios the software is tested against.