Lean User Story Template
I’d like to share my lean user story template (scroll down for the template).
There have been lots of books and articles written on the topic of user stories, so I won’t go very deep into details. But nevertheless I like to sketch out some — for me — important parts.
Why Stories at all?
Purpose: A user story tells us why are we doing things.
Conversation container: All collaborators can list their results and requirements. It is a living document.
Quality: A user story drives acceptance tests.
Planning: A story holds an estimate.
Implementation: A story drives the task planning.
What it is not: no UI, no tech bubble, focus on why and what, not how.
UX and the User Story
It is always written from a customer’s point of view: it is about needs, benefits and desired change in the life of a customer (user).
Agile & the User Story
First a story is as small as possible. What do we need for an first estimate? Later it should meet INVEST criteria and definition of ready.
Lean & the User Story
It is an experiment. It is Hypothesis driven. It is time-boxed.
“If the results don’t match your hypothesis, you’ve got data. If the results do match your hypothesis, then you have a discovery.” (Rob Shelton)
When do you NOT need a user story at all?
You do not have to write a user story when there is no assumption about a change in a user’s behavior which could be tested against a hypothesis. We need other tasks/tickets as well. But please do not call it User Story when it is about something different.
Before you write a User Story: Think lean!
These questions will ensure lean thinking through the process of specification. Answer those questions from time to time.
- What do we want to learn with this increment of the product?
- How can we measure this?
- What is the smallest thing we have to build for measuring?
Note: this is the Build-Measure-Learn loop, but it is reversed.
— The Lean User Story Template —
Sections one to five are mandatory, six and seven are bonus.
1. Assumption and purpose: What do we want to learn?
What we believe the user wants or needs, described in a meaningful pattern. This is the user value, it has to be positive, it has to be from a user’s perspective. Every team member and stakeholder has to understand the assumed user value.
Job Story Pattern:
Situation (when) — Motivation (I want) — Job to be done (so I can) — Outcome (meaningful change for my life)
or:
Lean UX pattern:
We believe that (doing this) — for (these people) — will achieve (this outcome) — we will know it is correct when (this happens).
2. Falsifiable Hypothesis: How can we measure it?
We need to validate or invalidate our assumption. This is the important part, it ensures validated learning after shipping to the user.
And: we have to take care about our feature when released to public.
Success (aka results, outcome) should be measurable and thus falsifiable.
If we cannot falsify we cannot learn.
Example:
- The KPI XY will increase by 10%.
3. Functional requirements: What do we have to build to measure it?
This is how we expect the feature to behave. The functional requirements are precisely listed, it is all about the feature.
Functional requirements are:
- Specific: There is no room for interpretation
- Measurable: We avoid undefined times or quantities
- We do not describe the user interface: We only describe WHAT the user can do, not HOW.
Example:
“User can navigate backwards and forward through a list of items. Each page shows 4”
NOT: “When the user clicks on the right arrow the horizontal list of circled user images slides nicely to the left.”
Ideally (automated) acceptance tests can be derived directly out of these requirements (see below).
Hint: think also about how the feature should NOT behave!
4. Tracking: How do we implement the measuring?
What do we need: clicks, taps, views … ? What KPI has to be calculated?
Do we ship it as a split test?
Example: track clicks and views, calc CTR
5. Non-functional requirements
It is important to draw a clear line between functional and non-functional requirements because of estimating and testing.
Non-functional reqs are describing everything what is not functional:
- Visual design
- Performance
- Usability
- “I want it nice”
Examples:
- PO says: “it feels good”
- See attached files for exact visual design
6. Bonus: Test cases
Functional Testing scenarios should be listed in GIVEN/WHEN/THEN format
- How do we test non-functional?
- Automation?
- Do we create regression tests?
And again: Please think about how the feature should NOT behave
7. Bonus: Task Planning
If we are really cool we list the technical tasks we need for planning.
Why this tpl is cool:
The template now holds for almost 2 years — it seems to be robust to change. I think the reason for that is that it respects multiple perspectives like JTBD, hypothesis thinking, lean, BDD and building for outcome in an organizational context. All those principles influenced the template.
“As a user …”
The template forces you on facing the truth because we cannot hide anymore behind “As a user I want …” stuff.
Who is the user? Who is I, me, the team? Am I the user? Is this some kind of empathy? What does she really want? How will she know if her wish has become true? How will we know?
If the team does not understand the user value — should we go on?
With this template just shipping and letting go our responsibility won’t work.
Hint: do not throw your user stories away after shipping. Move them to a experiment lane and timebox the experiment. Secure the learning part!
“Please take take care of your shipped increments — don’t let them alone“
Jan is an Entrepreneur and Product Guy living with his family in Hamburg, Germany. As a Consultant he helps companies with Lean Product Management and SEO. He is looking forward to connect!
