Posted in Scrum Add-ons

User Stories

Stories express something that will be valuable to a user (2)

Benefits of User Stories

  • They act as a placeholder to remind us to have conversations rather than follow written requirements contracts
  • They encourage interaction through the conversations
  • They are comprehensible by all, from devs and throughout the business, and have no technical jargon
  • They are the right size to be able to plan and estimate
  • When working iteratively we don’t have to write all stories upfront and can refine as we go along the project
  • To make clear the purpose
    • Example from Star Trek if he wants the date to be auto-logged rather than saying it out loud – is it to save him time or for audit logging? One is a lot stricter needs than the other! (4)
  • Focus on who it benefits
    • Example as a commuter, I want a car to drive to work. Very different if the commuter is a surburban commuter vs a farmer in South Dakota (4)

Splitting Stories

Vertical Slicing

  • Always slice stories from the point of view of our customer
  • All stories must have value, which can be to our customer directly or indirectly
  • The technical layers that make up the value are to be kept together (like the layers of a birthday cake) as one layer on its own does not provide value
  • Splitting stories into the technical layers can lead to defining the solution and restricting abilities to creatively iterate

Using Scenarios to Split Stories

  • See BDD and Three Amigos for writing stories with scenarios
  • Use these scenarios to break the story down into smaller pieces of value

Cake Metaphor (3)

Cake Metaphor Doodle
  • To split the story down you could break it down horizontally and take each ingredient in turn
  • But if you slice horizontally you will just get egg and not know if the cake ingredients all work together to provide value (it could taste awful all together!)
  • Instead, bake a cupcake!
  • You get all the ingredients but a smaller size to check the recipe works
A Cupcake Doodle!

User Story Construction

The Three C’s

  • Description that defers the details
As a [user type]
I want [functionality]
So that [benefit]
  • Verbal conversations are best
  • Highlights that we don’t know all the detail
  • Reminder of conversations we have had, work that has been done, any wider context
  • Acceptance Criteria
  • Must be matched for a story to be considered done
  • User point of view only
  • No design specifications unless the user wants them

Good User Story Guidance

INVEST Criteria

  • Stories shouldn’t have to be completed in a specific order and should not rely on another story to be started
  • This is not always achievable
  • Common examples are when you need something to exist before you can build upon it or when one story reduces the complexity of another making it seem logical to do them in a specific order
  • How do we respond to this?
    • Don’t put dependent stories in the same sprint to keep the flow
    • Join together dependent stories
  • Stories are not contracts – they are short descriptions of functionality
  • Open to discussion with the team
  • Simplify, alter, add to in whatever way is best for the goal and the product
  • Valued to user/ customer
  • Technology assumptions have no value to the customer!
  • Good size
  • Just enough information, but not too much to become confusing
  • If an investigation is needed before estimation, use a spike
  • Lower Limit is coffee break size, i.e. big enough that you deserve a coffee break for finishing
  • Scrum team will highlight size issues in refinement
  • Language is important
  • It must be specific, unlike “A user never has to wait for it to load”
  • “It takes two seconds max to load in 95% of cases” is much better

Acceptance Test Writing Guidance (2)

  • Always add tests as long as they add value
  • Capture assumptions
  • Provide basic criteria for when story is Done
  • Questions to ask
    • What else do devs want to know?
    • What am I assuming?
    • What can go wrong?
    • Circumstances where story might behave differently
    • Usability
    • Stress
    • Performance

Stories should be closed, not open ended

  • Use language to ensure that the stories have a definite closure
  • Continuous jobs are bad (e.g. managing an ad)
    • Instead use closed actions like “review responses” and “edit response”

User Story Card Example (3)

User Story Card Doodle
  1. Story reference number
  2. Author of the story
  3. Value/ importance
  4. Status/ release
  5. Size/ estimate
  6. Date created
  7. Dependencies
  8. Metrics (if relevant)
  9. Description
  10. Story title (this is the only mandatory field)

User Story Smells

Too Small

EVIDENCE: Frequent need to revise estimates depending on order

FIX: Combine the stories together

Not Independent

EVIDENCE: Difficulty in planning the iteration and lots of swapping stories in and out

FIX: Re-split the stories

Gold Plating

EVIDENCE: Extra wow factor being added that isn’t in the story

FIX: Increase the visibility in the Daily Scrum

Too Much Detail

EVIDENCE: Too long discussing the story

FIX: Strip the story back to its basics and focus on the user point of view

Trouble Prioritising

EVIDENCE: Stories cannot be prioritised logically

FIX: Stories may need to be broken down smaller or re-written from a value point of view


  1. The Scrum Guide
  2. User Stories Applied by Mike Cohn
  3. User Story Mapping by Jeff Patton
  4. Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland

Explore more



Posted in My Scrum Notes

User Story Mapping Workshop

“Story mapping keeps us focused on users and their experience, and the result if a better conversation, and ultimately a better product.” (1)

Exercise Walkthrough

Use the example of a morning routine for training for the people in the workshop

Start with talking about the Opportunity

Frame your idea

  • Why?
  • What are the benefits?

Put the opportunity into context

Talk about users and how this impacts them

  • Use personas

Build a narrative flow

Talk through the journey that each user will take to realise their benefit

  • Mile wide, inch deep
  • Tell a story
  • If there is a disagreement over the order, go with the most popular as it likely will not matter
  • Add in more steps for a good vs bad journey

Brainstorm Stories

All attendees brainstorm stories and stick them underneath each of the narrative flow steps that they apply to

  • Explore details and options
  • Specific things the user will do
  • Alternate things the user could do
  • Include risk stories
  • What would make it cool?
  • Play the ‘What about?’ game
    • E.g. What about when things go wrong?

Organise the Stories

Collate similar stories and talk high level about each of the stories so all in the room have a shared understanding.

  • Move all the stories down the wall to leave a gap at the top as you talk through them
  • Draw a line across the board (blue line on above picture) below the gap that has been left

Outcome #1 Focus

Discuss and decide what Outcome #1 can be

  • Top outcome is sea level
  • For maximum learning
  • Opening game

Outcome #1 Populate

Work together to decide which stories are part of Outcome 1

  • Move only the stories up above the line that are necessary for Outcome 1
  • Not all the steps from the narrative flow must be present in the Outcome
  • Move the stories from below Outcome 1 down to make a gap


Repeat steps 6 – 9 with the next Outcome until you have:

  • Middle outcome is the fish
  • Business rules
  • Wider user journey
  • Performance


  1. User Story Mapping by Jeff Patton

Explore more

User Stories

Posted in Games

User Story Mad Libs

A quick team builder game


Mad Libs, for those who are unfamiliar, is defined below from the Wiki definition:

“Mad Libs is a phrasal template word game where one player prompts others for a list of words to substitute for blanks in a story, before reading the – often comical or nonsensical – story aloud. The game is frequently played as a party game or as a pastime.”


  1. Create paragraph from the User Story structure you use. My example is below
As a [person]
I want a [noun] 
So that I can [verb][adverb] 

GIVEN I have a [noun] 
WHEN I [verb][adverb]
THEN I can [verb] better. 

Acceptance Criteria 
1. I can [verb] when I [verb] on the [noun]   
2. If I select the [noun] I am shown the [noun]

2. Note the list of words you need to be filled in

Person x 1 
Noun x 5 
Verb x 5 
Adverb x 2


  1. Do not show your team the User Story paragraph as this gives the game away
  2. Ask each person in turn to name one of the lists of words
  3. Read aloud the finished story that you have all created together


  • A lot of laughter
  • Team building from doing something silly and creative together – there are no wrong answers in this game!
  • Getting to know each other a bit more from what the first word that came into people’s heads


In the future I would like to try using this to teach User Story writing or BDD scenarios. I think it could be a good tool to act as a template for a simple User Story and could help create a conversation over structure and language.