The document provides information on user stories, including what they are, how to write them, and best practices. Some key points: - A user story is a high-level definition of a requirement written from the user's perspective that provides enough information for developers to estimate effort. It focuses on who needs what and why, not how. - User stories should follow the INVEST criteria: independent, negotiable, valuable, estimable, sized appropriately, and testable. Acceptance criteria define when a story is complete. - Epics are large stories that need to be broken down into smaller stories over multiple iterations. Themes group related stories. - Best practices for writing stories include keeping them

1. Stefano Leli, Fabio Armani
User Story Writing
f.armani@open-ware.org - stefano.leli@gmail.com

2. What were they thinking?
Team
Product owner

3. What were they thinking?
• Chose a product owner for each team
• Product owners may only communicate with the
team through imperatives (“it must have/do...”)
or similes (“it’s like...”)
• Cannot use the name of the thing in a sentence
(“it must pour tea” for a teapot is not allowed)
• Teams cannot ask questions
• Teams have 2 minutes to draw the object seen
by the PO

8. Star Trike

9. Moto RV

11. User Story Writing
Fabio Armani, Stefano Leli stefano.leli@gmail.com - f.armani@open-ware.org
What is a "User Story”

12. User Story: is
• A User Story is a very high-level definition of a
requirement, containing just enough information
so that the developers can produce a
reasonable estimate of the effort to implement
it.
• A User Story is a proposed solution from a user’s
perspective.
• User Stories have Acceptance Criteria (or
Conditions of Satisfaction) and Validations.

13. User Story
• The user story also serves as a metaphor for our
entire, incremental-value-delivery approach, i.e.:
– define a valuable user value story
– implement and test it in a short iteration
– demonstrate/and or deliver it to the user
– capture feedback
– validate it from a business perspective
– learn
– repeat forever!

14. User Story
• The user story can describe:
– Features
– Non-Functional Requirements
– Bug Fixes
• It is the primary development artifact in XP/
Agile development methodology
• High level requirements document
• Focuses on Who, What and Why of a feature
and not How

15. What a "User Story" is not

16. User Story: is not
• It is not a use case or a software requirement,
i.e. a formal and long specification document
• One of the biggest misunderstandings with user
stories is how they differ from traditional
requirements specifications

19. User Role: modeling
• User Roles
– Various types of users
• Role Modeling
– Brain storming
– Organizing
– Consolidating
– Refining
• Personas
– Imaginary representation of an User Role
– Could use pictures too
• Extreme Characters

20. User
Tester UX
Dev BA
PO SM

21. User Stories: gathering
• User Interviews
– Select right interviewees
– Ask open-ended, context-free questions
• Questionaries
– Best if there is a large user population
– When you need answers to specific questions
• Observation
– Best for In-House developments
• Story writing Workshops
– Effective during the initial phase of the project / release

22. Coin Sorting
How long will it take to sort this bag of coins?

24. 3C
Card, conversation & confirmation

27. user stories need to be short and
concise enough so that they can fit
on a single card

30. the conversation is much much
more important than the story itself

33. by definition, user stories must be
testable

34. A User Story should cut
throughout all the layers of the
architecture

35. Initial User Stories (informal)

36. Example User Stories
Students can purchase monthly parking passes online.
Parking passes can be paid via credit cards.
Parking passes can be paid via PayPal ™.
Professors can input student marks.
Students can obtain their current seminar schedule.
Students can order official transcripts.
Students can only enroll in seminars for which they have prerequisites.
Transcripts will be available online via a standard browser.

37. #52
Students can purchase monthly
parking passes online
Priority: 8
Estimate: 4

38. Initial User Stories (formal)

39. #
User Story Title
As a <user role> I want to
<goal> so that I can achieve
some <benefit>.

40. #52
Purchase Monthly Parking Pass
As a student I want to purchase
an online monthly parking pass
so that I can drive to school.

41. #52
Purchase Monthly Parking Pass
As a student I want to purchase
an online monthly parking pass
so that I can drive to school.
Priority: Must
Estimate: 5

42. #97
Find Reviews Near Address
As a typical user I want to see unbiased
reviews of a restaurant near an address
so that I can decide where to go for
dinner. Priority: Must
Estimate: 8

43. #97
Find Reviews Near Address
As a typical user I want to see unbiased
reviews of a restaurant near an address
so that I can decide where to go for
dinner. Priority: Should
Estimate: 5

45. what makes a good story
Bill Wakefield is credited with this acronym

46. INVEST in User Stories
• Independent
– Avoid dependencies with other stories
– Write stories to establish foundation
– Combine stories if possible to deliver in a single iteration
• Negotiable
– Stories are not a contract
– Too much detail up front gives the impression that more discussion on
the story is not necessary
– Not every story must be negotiable, constraints may exist that prevent
it
• Valuable
– Each story should show value to the Users, Customers, and
Stakeholders

47. INVEST in User Stories
• Estimable
– Enough detail should be listed to allow the team to estimate
– The team will encounter problems estimating if the story is too big, if
insufficient information is provided, or if there is a lack of domain
knowledge
• Sized Appropriately
– Each story should be small enough to be completed in a single iteration
– Stories that may be worked on in the near future should be smaller and
more detailed
– Larger stories are acceptable if planned further out (Epics)
• Testable
– Acceptance criteria should be stated in customer terms
– Tests should be automated whenever possible
– All team members should demand clear acceptance criteria

48. Independent

49. Independent

51. (Hands-On)

53. Acceptance Criteria
• Acceptance criteria define the boundaries
of a user story, and are used to confirm
when a story is completed and working as
intended.

54. Acceptance Criteria
• AC represent high-level criteria from the
perspective of the user or stakeholder.
• It’s important to consider Positive and
Negative criteria.
• The PO should collaborate with testers to
create good Acceptance Criteria
(Conditions of Satisfactions).

55. #73
Upload Files
AS A wiki user I WANT to upload a file to
the wiki SO THAT I can share it with my
colleagues

56. Conditions of Satisfactions
Verify with .txt and .doc files
Verify with .jpg, .gif and .png files
Verify with .mp4 files <= 1 GB
Verify no DRM-restricted files

57. #85
View Attachments in Messages
AS A user viewing messages that contain more than
simple text
I WANT to be able to open them and see the
contents
SO THAT I can view the additional information and
understand the message fully

58. Acceptance Criteria
As a conference attendee, I want to be able to register
online, so I can register quickly and cut down on
paperwork.
Acceptance Criteria:
1. A user cannot submit a form without completing all the mandatory
fields
2. Information from the form is stored in the registrations database
3. Protection against spam is working
4. Payment can be made via credit card
5. An acknowledgment email is sent to the user after submitting the
form.

59. Acceptance Criteria
As a conference organizer, I want to send a ticket via
email at the end of the online registration so that I can
speed up the check-in process.
Acceptance Criteria:
1. The attendee must be inform that he will receive an email with an
electronic ticket
2. The email has been sent correctly
3. The electronic ticket must have a QR code
4. The QR code must be readable by a smartphone camera

60. Give-When-Then
• Given-When-Then is a useful format for
expressing testable acceptance criteria
• Created by Dan North
Given <context>
When <action>
Then <expected result>

61. Feature
A user can view attachments, links,
images and stories contained within
messages

62. #39
View Attachments in Messages
AS A user viewing messages that contain more than
simple text
I WANT to be able to open them and see the
contents
SO THAT I can view the additional information and
understand the message fully

63. Acceptance Criteria
As a user I want to open the attachments contained in an
email so that I can view the additional information and
fully understand the message.
Acceptance Criteria:
1. The user opens a message that contains a file attachment or story
2. The user opens a message that contains a link
3. The user opens a message that contains an image

64. Acceptance Criteria
View Attachments in Messages
Acceptance Criteria:
Scenario: The user opens a message that contains a file attachment or
story
GIVEN the message contains a file attachment or story
WHEN I click the message link to open the message
THEN the message opens and shows the attached file or story

65. Acceptance Criteria
View Attachments in Messages
Acceptance Criteria:
Scenario: The user opens a message that contains a link
GIVEN the message contains a link
WHEN I click the message link to open the message
THEN the message opens and shows the link as an active hyperlink

66. Acceptance Criteria
View Attachments in Messages
Acceptance Criteria:
Scenario: The user opens a message that contains a file attachment or
story
GIVEN the message contains a file attachment or story
WHEN I click the message link to open the message
THEN the message opens and shows the attached file or story

67. Acceptance Criteria
View Attachments in Messages
Acceptance Criteria:
Scenario: The user opens a message that contains an image
GIVEN the message contains an image attachment
WHEN I click the message link to open the message
AND hover my mouse of the image file posted in the message
THEN the image can be viewed as a thumbnail

68. Pros & Cons
ü Short and Easy to modify as in when requirements
changes
ü Allow projects to be broken into small increments
ü Easier to estimate the development effort
ü Completed User stories can go for development
ü It drives the creation of Acceptance tests
û Initial learning curve
û They require close customer contact
û Rely more on competent developers

69. User Stories Applied
• Mike Cohn

70. User Story Writing
Fabio Armani, Stefano Leli stefano.leli@gmail.com - f.armani@open-ware.org
stefano.leli@gmail.com f.armani@open-ware.org
@sleli @fabioarmani

73. Epics
• Epics are large user stories, typically ones
which are too big to implement in a single
iteration and therefore they need to be
disaggregated into smaller user stories at
some point.

74. Preference Training Epic
As a typical user I want to train the system on what
types of product and service reviews I prefer so it will
know what characteristics to use when filtering
reviews on my behalf

79. Themes
• A theme is a collection of related user stories.
• For example, for a university registration system
there might be themes around students, course
management, transcript generation, grade
administration, financial processing.
• Themes are often used to organize stories into
releases or to organize them so that various sub-
teams can work on them.

80. Keywords Training Theme
As a typical user I want to train the system on what
keywords to use when filtering reviews so I can filter
by words that are important to me

81. From Features to Tasks
Epic
Feature
Story

82. Managing Epics
• Epics are too large to estimate and can be split into
multiple stories
• Epics represents
– Complex functionality
– Placeholders for low priority stories
• Types of Epics
– Compound Stories
– Complex Stories
• Different ways to split Epics
– Various small actions in the Epic
– Along the boundaries of Data
– Depending on complexity

83. Managing Tiny Stories
• Tiny stories are too short
• Its better to
– Combine multiple tiny stories
– Group them into Themes

84. Creating User Stories
• Sequentially numbered
• Customer Focused
– Written from a User's perspective
– Better if written by the user
– Avoid technical jargons
• Shouldn't be too short nor too long
• Should be complete and testable
• Should be able to implement by two people in a single
iteration
• Avoid infrastructure, technology or service elements

86. Talking to Users
• Ask open ended questions
– closed = “Yes or No”
– open = “What would you be willing to trade for performance?”
• Give user options (“This one or that one?”)

87. Story Writing
Story writing with your customer:
• Low fidelity prototypes to get the main flows
• Get breadth first
• Use user roles / personas to help identify missing stories
• Compare against competing products

88. Decomposing Stories
• Compound Stories
– a number of smaller stories / scenarios
– split into meaningful chunks
• Complex Stories
– if it’s largely unknown, consider a spike
– try find ‘natural’ seams in the story
• Combining stories
– stories should be about 2 days work
– if too small combine e.g. bugs into one story

89. Splitting Stories

90. Splitting Stories
• Patterns for splitting stories:
– Workflow steps
– Business rule variations
– Major / Minor effort
– Simple / Complex
– Variations in available data
– Data entry methods
– Defer performance
– Operations (e.g. create / update / delete)
– Spike

91. (Hands-On)

93. Technical Stories

94. Technical Stories
• Adding CI, optimizing DB, upgrade to latest Oracle, etc.
– Consider trying to write a user story so that you are forced to
define the business value
• No user facing functionality, e.g. Rating engine
consumes some output
– Consider writing as a user story with the engine as the user
– e.g: As the rating engine, I want well formed CDR’s so that I can
minimize error logging
Don’t hurt yourself trying to force it; sometimes it’s OK not to
use the format
Be careful that these aren’t tasks that have been elevated to
stories ...

95. Story: smells
• Too small or too big
• Estimates don’t converge
• No scenarios / acceptance criteria
• Interdependent
• Gold-plating

96. Story: more smells
• Too detailed
• UI defined
• Thinking too far ahead
• Splitting too frequently
• Trouble prioritising
• Technical language

97. Pros & Cons
ü Short and Easy to modify as in when requirements
changes
ü Allow projects to be broken into small increments
ü Easier to estimate the development effort
ü Completed User stories can go for development
ü It drives the creation of Acceptance tests
û Initial learning curve
û They require close customer contact
û Rely more on competent developers

98. User Stories Applied
• Mike Cohn

99. User Story Writing
Fabio Armani, Stefano Leli stefano.leli@gmail.com - f.armani@open-ware.org
stefano.leli@gmail.com f.armani@open-ware.org
@sleli @fabioarmani