Ep07: TL;DR: User Story Writing
Everyone has heard of User Stories, most delivery teams use them, most business analysts or product owners write them, but often we are not writing them well.
Here is our 5 minute fix to help you write great stories.
First: set the scene
As a <user> I want to <action> so that <goal>
This gives you the who, what and why. Like a little business case.
Generally speaking, this should be written so that we don’t need much context to understand it.
“As an ecommerce merchant I want to present a Logo on my payment page as to provide a consistent brand experience so that when my customers provide payment details they are not confused or concerned.”
Second: add detail people can work off
Provide relevant detail needed for implementation and validation (testing). This we call Acceptance Criteria.
Where conditions are important, use Gherkin format:
GIVEN <condition> WHEN <action> THEN <result>
This facilitates clear communication and helps testing.
GIVEN an image has been successfully provided
WHEN I view the pay page
THEN I see the logo
Of course there will may other ACs, around business rules, exceptions, alternative courses, non functional requirements, etc…
Third: get the level right
An individual story should provide a testable part of a feature, i.e. something end to end. But it should be possible to delivery it within a Sprint. Better, within a couple of days.
- Iterate: start high level, work with UX / Dev / QA to refine
- Attempt to write all stories at a similar size
- Split stories in a meaningful way. Normally that means end to end. No FE/BE split. This is complicated. We will have a separate episode on that.
- Add as little detail as possible but as much as is needed from your team
- Do not write stories in sprint planning. Write them before. Only validate their readiness in Sprint planning
- Do not use stories instead of communication
- Do not turn stories into specs
- Do not confuse technical tasks with user stories