Every feature the team builds starts as a few sentences about a person. User stories come straight after the feature scope: the written scope names each feature by its stories, and each story carries the scenarios that test it.
By the end of this module, you can capture user requirements and turn them into clear, concise user stories, each with criteria a test can check. Module 4 follows one story like these, a customer placing an order with the card she chose, all the way to a Haskell API and the review before launch, in One feature, scope to launch.
Objectives
- Understand the importance of user-centric design.
- Learn to capture user requirements effectively.
- Translate user needs into user stories.
Topics
Defining user stories
A user story is a short, plain description of a feature, told from the side of the person who uses it: what they want, and why.
Identifying user needs
A story is only as good as the need under it, and the real need is often not the first thing anyone asks for. Finding it takes listening, and a few plain questions.
Writing clear and concise user stories
A good story is one sentence that the owner and every webmaster on the job read the same way, and it guides the work from there.
Activities
- Practical exercises in creating user stories: writing user stories from user needs, hands on.
- Collaborative sessions to review and refine user stories: working together until each story is well structured and each of its criteria can be tested.
User stories are the bridge between what people need and the software you build. On the software side of that bridge, the lecture What Is a Function? sets out the pure functions the code is built from.
The next module, on behavior-driven development (BDD), carries each story into scenarios the owner can read and a test can run.
It all starts with a good story, and a good story starts with the person who needs it, where Understanding the importance of user-centric design, the next lesson, begins.