User stories writing   - Codemotion 2013
Upcoming SlideShare
Loading in...5
×
 

User stories writing - Codemotion 2013

on

  • 672 views

Stefano Leli (Freelance) - Fabio Armani (OpenWare) ...

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.

Statistics

Views

Total Views
672
Views on SlideShare
642
Embed Views
30

Actions

Likes
0
Downloads
9
Comments
0

2 Embeds 30

http://lanyrd.com 29
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    User stories writing   - Codemotion 2013 User stories writing - Codemotion 2013 Presentation Transcript

    • Stefano Leli, Fabio ArmaniUser Story Writingf.armani@open-ware.org - stefano.leli@gmail.com
    • What were they thinking? TeamProduct owner
    • 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 stefano.leli@gmail.com - f.armani@open-ware.orgWhat 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 Tester UX Dev BA PO SM
    • 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 SortingHow long will it take to sort this bag of coins?
    • 3CCard, conversation & confirmation
    • user stories need to be short andconcise enough so that they can fit on a single card
    • the conversation is much muchmore important than the story itself
    • by definition, user stories must be testable
    • A User Story should cutthroughout all the layers of thearchitecture
    • Initial User Stories (informal)
    • Example User StoriesStudents 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.
    • #52 Students can purchase monthly parking passes online Priority: 8 Estimate: 4
    • Initial User Stories (formal)
    • # User Story TitleAs a <user role> I want to<goal> so that I can achievesome <benefit>.
    • #52 Purchase Monthly Parking PassAs a student I want to purchasean online monthly parking passso that I can drive to school.
    • #52 Purchase Monthly Parking PassAs a student I want to purchasean online monthly parking passso that I can drive to school. Priority: Must Estimate: 5
    • #97 Find Reviews Near AddressAs a typical user I want to see unbiasedreviews of a restaurant near an addressso that I can decide where to go fordinner. Priority: Must Estimate: 8
    • #97 Find Reviews Near AddressAs a typical user I want to see unbiasedreviews of a restaurant near an addressso that I can decide where to go fordinner. Priority: Should Estimate: 5
    • what makes a good storyBill 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)
    • 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).
    • #73 Upload FilesAS A wiki user I WANT to upload a file tothe wiki SO THAT I can share it with mycolleagues
    • Conditions of SatisfactionsVerify with .txt and .doc filesVerify with .jpg, .gif and .png filesVerify with .mp4 files <= 1 GBVerify no DRM-restricted files
    • #85 View Attachments in MessagesAS A user viewing messages that contain more thansimple textI WANT to be able to open them and see thecontentsSO THAT I can view the additional information andunderstand the message fully
    • 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 fields2.  Information from the form is stored in the registrations database3.  Protection against spam is working4.  Payment can be made via credit card5.  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 ticket2.  The email has been sent correctly3.  The electronic ticket must have a QR code4.  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
    • #39 View Attachments in MessagesAS A user viewing messages that contain more thansimple textI WANT to be able to open them and see thecontentsSO THAT I can view the additional information andunderstand the message fully
    • Acceptance CriteriaAs 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 story2.  The user opens a message that contains a link3.  The user opens a message that contains an image
    • Acceptance Criteria View Attachments in MessagesAcceptance Criteria:Scenario: The user opens a message that contains a file attachment orstoryGIVEN the message contains a file attachment or storyWHEN I click the message link to open the messageTHEN the message opens and shows the attached file or story
    • Acceptance Criteria View Attachments in MessagesAcceptance Criteria:Scenario: The user opens a message that contains a linkGIVEN the message contains a linkWHEN I click the message link to open the messageTHEN the message opens and shows the link as an active hyperlink
    • Acceptance Criteria View Attachments in MessagesAcceptance Criteria:Scenario: The user opens a message that contains a file attachment orstoryGIVEN the message contains a file attachment or storyWHEN I click the message link to open the messageTHEN the message opens and shows the attached file or story
    • Acceptance Criteria View Attachments in MessagesAcceptance Criteria:Scenario: The user opens a message that contains an imageGIVEN the message contains an image attachmentWHEN I click the message link to open the messageAND hover my mouse of the image file posted in the messageTHEN 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 stefano.leli@gmail.com - f.armani@open-ware.orgstefano.leli@gmail.com f.armani@open-ware.org@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 EpicAs a typical user I want to train the system on whattypes of product and service reviews I prefer so it willknow what characteristics to use when filteringreviews 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 ThemeAs a typical user I want to train the system on whatkeywords to use when filtering reviews so I can filterby words that are important to me
    • From Features to Tasks Epic FeatureStory
    • 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 Users perspective –  Better if written by the user –  Avoid technical jargons•  Shouldnt 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 WritingStory 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)
    • 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 stefano.leli@gmail.com - f.armani@open-ware.orgstefano.leli@gmail.com f.armani@open-ware.org@sleli @fabioarmani