user stories writing - codemotion 2013
DESCRIPTION
Stefano Leli (Freelance) - Fabio Armani (OpenWare) Scrivere user stories dovrebbe essere facile...almeno in teoria. In realtà nella pratica ci troviamo troppo spesso a combattere con storie vaghe o troppo tecniche, storie che non possono essere testate o addirittura che non portano alcun valore. In questo workshop cercheremo assieme di comprendere la differenza tra requisiti funzionali e User Story, tra User Story e Use Case, mediante dei case study.TRANSCRIPT
What were they thinking?
Product owner
Team
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
Star Trike
Moto RV
User Story Writing Fabio Armani, Stefano Leli
What is a "User Story”
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.
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!
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
What a "User Story" is not
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
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
User
UX
BA
SM PO
Dev
Tester
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
Coin Sorting
How long will it take to sort this bag of coins?
3 C Card, conversation & confirmation
user stories need to be short and
concise enough so that they can fit
on a single card
the conversation is much much
more important than the story itself
by definition, user stories must be
testable
A User Story should cut throughout all the layers of the architecture
Initial User Stories (informal)
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.
Students can purchase monthly
parking passes online
#52
Priority: 8 Estimate: 4
Initial User Stories (formal)
User Story Title As a <user role> I want to <goal> so that I can achieve some <benefit>.
#
Purchase Monthly Parking Pass As a student I want to purchase an online monthly parking pass so that I can drive to school.
#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
#52
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.
#97
Priority: Must Estimate: 8
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.
#97
Priority: Should Estimate: 5
what makes a good story
Bill Wakefield is credited with this acronym
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
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
Independent
Independent
(Hands-On)
3DUWHFLSDQWL3DUWHFLSDQWL3DUWHFLSDQWL3DUWHFLSDQWL 5HJLVWUD]LRQH
6SHDNHU6SHDNHU6SHDNHU6SHDNHU %LRJUDILD
6HVVLRQL�3URSRVWH
2UJDQL]]DWRUL2UJDQL]]DWRUL2UJDQL]]DWRUL2UJDQL]]DWRUL 5HJLVWUD]LRQH6HUYL]L6HUYL]L6HUYL]L6HUYL]L3UHQRWD]LRQH%LJOLHWWL&RQIHUHQ]D
$FTXLVWR3DJDPHQWR
)DWWXUD]LRQH
&�3&�3&�3&�3$SHUWXUD
&KLXVXUD
L&RQIL&RQIL&RQIL&RQI
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.
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).
Upload Files AS A wiki user I WANT to upload a file to
the wiki SO THAT I can share it with my
colleagues
#73
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
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
#85
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.
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
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>
Feature
A user can view attachments, links, images and stories contained within
messages
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
#39
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
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
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
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
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
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
User Stories Applied
• Mike Cohn
User Story Writing Fabio Armani, Stefano Leli [email protected] - [email protected]
@sleli
@fabioarmani
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.
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
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.
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
From Features to Tasks
Epic
Feature
Story
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
Managing Tiny Stories • Tiny stories are too short • Its better to
– Combine multiple tiny stories – Group them into Themes
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
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?”)
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
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
Splitting Stories
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
(Hands-On)
3DUWHFLSDQWL3DUWHFLSDQWL3DUWHFLSDQWL3DUWHFLSDQWL 5HJLVWUD]LRQH
6SHDNHU6SHDNHU6SHDNHU6SHDNHU 6HVVLRQL�3URSRVWH
%LRJUDILD
2UJDQL]]DWRUL2UJDQL]]DWRUL2UJDQL]]DWRUL2UJDQL]]DWRUL 5HJLVWUD]LRQH
6HUYL]L6HUYL]L6HUYL]L6HUYL]L
3UHQRWD]LRQH
%LJOLHWWL&RQIHUHQ]D
:RUNVKRS
&XPXODWLYR
6HUYL]L�$FFHVVRUL3UDQ]R
+RWHO
0DJOLHWWD�*DGJHW
$FTXLVWR
3DJDPHQWR
)DWWXUD]LRQH
6FRQWL
6WXGHQWH
*UXSSL
&RXSRQ
7ZLWWHU
3RVW�9HQGLWD6SHGL]LRQH�%LJOLHWWL
0RGLILFD�&DQFHOOD]LRQH
&�3&�3&�3&�3
$SHUWXUD
*HVWLRQH�3URSRVDO,QYLR��6SHDNHU�
&RQVXOWD]LRQH��2UJDQL]]DWRUL�
&KLXVXUD
L&RQIL&RQIL&RQIL&RQI
Technical Stories
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 ...
Story: smells
• Too small or too big • Estimates don’t converge • No scenarios / acceptance criteria • Interdependent • Gold-plating
Story: more smells
• Too detailed • UI defined • Thinking too far ahead • Splitting too frequently • Trouble prioritising • Technical language
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
User Stories Applied
• Mike Cohn
User Story Writing Fabio Armani, Stefano Leli [email protected] - [email protected]
@sleli
@fabioarmani