Many teams refer to each piece of work they do as a User Story. Many write some words into some kind of ticket in Jira or Rally (and sometimes a sticky-note), with the words ‘As a… I want… So that…”. But are you really working with User Stories? In this talk, Antony takes you back to the origins of User Stories; explains how they have been misunderstood and accidentally misrepresented; how the practice has been interpreted through filters of older ways of working and have now become something other than they were intended for the vast majority of teams. In most teams Antony has visited or begun to coach, their idea of User Stories and his are very different. Many of their User Stories are not independently valuable and have dependencies on many others. Real value isn’t unlocked until several stories later. There’s little room to negotiate as the piece of work has only one solution… the one specified. After some guidance, these teams soon realise that what they once called User Stories were actually tasks and features in disguise. And, by understanding the art of User Stories – beyond simply what we write –. they were able to release more value, sooner, with more flexibility and without dependencies.

1. User Stories Re-Explained
@AntonyMarcano
@RiverGlide

2. @AntonyMarcano
antonymarcano.com
Antony Marcano is co-founder of RiverGlide, a company that guides
organisations in all aspects of agility. Most of his 20+ years experience
has been with Agile teams & guiding organisations that aspire to
greater agility.
Antony is acknowledged in numerous books on Agile, BDD, and
crafting software. He was also successor to Mike Cohn and Brian
Marick as Technical Editor for Better Software Magazine and has
spoken regularly at Oxford University on Agile Methods.
Antony Marcano

3. Implied Requirements
Select and name chunks of functionality. Use
names that would have meaning to customers
consistent with the Product Initiative. Allow these
names to imply customer requirements without
actually enumerating requirements in the
traditional sense.
c2.com/doc/episodes.pdf
circa 1995

4. Business users write a story
describing something the
system needs to do

6. ronjeffries.com/xprog/articles/expcardconversationconfirmation/

7. ronjeffries.com/xprog/articles/expcardconversationconfirmation/

8. ronjeffries.com/xprog/articles/expcardconversationconfirmation/

9. Tasks: What you do, to implement…
Features: Attributes the product has, that provide…
Functionality: Things the product does
“Requirement”: An unproven idea that someone important believes in
Words often used…

10. “The Sapir–Whorf hypothesis, also known as the
linguistic relativity hypothesis, refers to the proposal that the
particular language one speaks influences the way one thinks
about reality”
https://www.sciencedirect.com/topics/psychology/sapir-whorf-hypothesis
Sapir-Whorf Hypothesis

11. A User Story is
literally just that…
A user’s story, told in terms of
what they need to achieve
tomorrow and why. Each story has
an independently valuable
outcome for a user, no matter how
small.
We write down just enough to
remember the user’s story.

13. Managing the development of large software systems– Dr. Winston W. Royce, 1970

14. 14
Credit:HenrikKniberg

15. 15
Credit:HenrikKniberg

16. 16
Credit:HenrikKniberg

22. A template doesn’t
make it a User Story
User Story Mapping – Jeff Patton

23. “The Net” (1995)

28. The Card is Not The Story

29. “Good documents are like vacation photos.”
-Jeff Patton

30. The famous pipe. How people reproached
me for it! And yet, could you stuff my pipe?
No, it's just a representation, is it not? So if I
had written on my picture 'This is a pipe', I'd
have been lying!
— René Magritte
https://en.wikipedia.org/wiki/The_Treachery_of_Images

31. “Stories are told”-Ron Jeffries

32. “User Stories” is a way of working
that, through conversation, helps
teams and users come to a shared
understanding of the problems the
users need solved and why it
matters to them.
It lets the discovery of the best
solution happen during
implementation, with small,
valuable evolutions to the
product, both incrementally and
iteratively.

33. Conversations are how
We understand the
user’s story

35. A Task: What you do, to implement…
A Feature: Attributes the product has, that provide…
Functionality: Things the product does
“Requirement”: An unproven idea that someone important wants
A User Story isn’t…

36. A User Story is…
A user’s story, told in terms of what
they need to achieve tomorrow and
why. Each story has an
independently valuable outcome
for a user, no matter how small.
We write down just enough to
remember the user’s story.

37. “User Stories” is a way of working
that, through conversation, helps
teams and users come to a shared
understanding of the problems the
users need solved and why it
matters to them.
It lets the discovery of the best
solution happen during
implementation, with small,
valuable evolutions to the product,
both incrementally and iteratively.

39. Managing the development of large software systems– Dr. Winston W. Royce, 1970

40. 40
Credit:HenrikKniberg

42. The End
antony@riverglide.com
@AntonyMarcano
riverglide.com
@RiverGlide