• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
User Stories writing - Bettersoftware 2012
 

User Stories writing - Bettersoftware 2012

on

  • 738 views

These are the slides of the workshop on "User Story Writing" I held with Stefano Leli @Bettersoftware 2012.

These are the slides of the workshop on "User Story Writing" I held with Stefano Leli @Bettersoftware 2012.

Statistics

Views

Total Views
738
Views on SlideShare
735
Embed Views
3

Actions

Likes
7
Downloads
15
Comments
0

1 Embed 3

http://www.pinterest.com 3

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

User Stories writing - Bettersoftware 2012 User Stories writing - Bettersoftware 2012 Presentation Transcript

  •   openware  Stefano  Leli   Fabio  Armani   stefano.leli@gmail.com armani.fabio@gmail.com @sleli @fabioarmani
  • What  is  a  User  Story?  
  • User  Story:  is  •  A  user  story  is  a  very  high-­‐level  defini@on  of  a   requirement,  containing  just  enough   informa@on  so  that  the  developers  can   produce  a  reasonable  es@mate  of  the  effort  to   implement  it.  
  • User  Story  •  Define  a  valuable  user  value  story  •  implement  and  test  it  in  a  short  itera5on  •  demonstrate/and  or  deliver  it  to  the  user  •  capture  feedback  •  learn  •  repeat  forever!  
  • What  a  "User  Story"  is  not  
  • User  Story:  is  not  •  It  is  not  a  use  case  or  a  soIware  requirement,   i.e.  a  formal  and  long  specifica@on  document  •  One  of  the  biggest  misunderstandings  with   user  stories  is  how  they  differ  from  tradi@onal   requirements  specifica@ons  
  • Ini@al  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.  
  • #52 Students can purchase monthly parking passes online Priority: 8 Estimate: 4
  • Ini@al  User  Stories  (formal)  
  • As  <type  of  user>,  <func5on>  so  that  I  can   achieve  <some-­‐goal>  
  • #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
  • 3  C  
  • 3  C  Card,  conversa@on  &  confirma@on  
  • Card  
  • user  stories  need  to  be  short  and   Card  concise  enough  so  that  they  can  fit  on   a  single  card  
  • Conversa@on  
  • Conversa@on  the  conversa@on  is  much  much  more   important  than  the  story  itself  
  • Confirma@on  
  • Confirma@on  by  defini@on,  user  stories  must  be   testable    
  • INVEST    in  your  User  Stories  
  • INVEST  in  User  Stories  •  Independent   Avoid  dependencies  with  other  stories   Write  stories  to  establish  founda@on   Combine  stories  if  possible  to  deliver  in  a  single  itera@on  •  Nego+able   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  nego@able,  constraints  may  exist  that  prevent  it  •  Valuable    Each  story  should  show  value  to  the  Users,  Customers,  and  Stakeholders  
  • INVEST  in  User  Stories  •  Es+mable   Enough  detail  should  be  listed  to  allow  the  team  to  es@mate   The  team  will  encounter  problems  es@ma@ng  if  the  story  is  too  big,  if  insufficient   informa@on  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  itera@on   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  
  • User  Stories  (planning)  
  • Epics  
  • Epics  •  Epics  are  large  user  stories,  typically  ones   which  are  too  big  to  implement  in  a  single   itera@on  and  therefore  they  need  to  be   disaggregated  into  smaller  user  stories  at   some  point.      
  • Themes  
  • Themes  •  A  theme  is  a  collec@on  of  related  user  stories.    •  For  example,  for  a  university  registra@on   system  there  might  be  themes  around   students,  course  management,  transcript   genera@on,  grade  administra@on,  financial   processing.  •  Themes  are  oIen  used  to  organize  stories  into   releases  or  to  organize  them  so  that  various   sub-­‐teams  can  work  on  them.  
  • Kano  Model  According  to  Kano,  there  are  3  classes  of  features:  •  Prerequisites  -­‐  If  your  product  doesn’t  have  these   features,  it  will  immediately  be  removed  from   considera@on.  Who  wants  a  house  without  a   bathroom?  •  Linear  Features  -­‐  The  more  the  be]er,  but  their  higher   the  cost.  A  family  that  wants  three  bedrooms  will  not   consider  a  house  with  one,  but  they  might  consider  a   house  with  2  or  4  bedrooms.  •  Exciters  -­‐  Unique  features  which  only  this  product  has   and  which  convince  the  customer  to  say  “Yes!  I  want   it!  This  one  and  no  other”  
  • CMS  1.0   (Hands-­‐On)      
  • User  Story  (spligng)  
  • CMS  1.1   (Hands-­‐On)      
  • Benefits  
  • Benefits  •  XP  and  other  agile  methodologies  favor  face-­‐ to-­‐face  communica@on  over  comprehensive   documenta@on  and  quick  adapta@on  to   change  instead  of  fixa@on  on  the  problem.  
  • User  stories  achieve  this  by:  •  Being  very  short.  They  represent  small  chunks  of  business  value  that  can   be  implemented  in  a  period  of  days  to  weeks.  •  Allowing  developer  and  the  client  representa@ve  to  discuss  requirements   throughout  the  project  life@me  •  Needing  very  li]le  maintenance  •  Only  being  considered  at  the  @me  of  use  •  Maintaining  a  close  customer  contact  •  Allowing  projects  to  be  broken  into  small  increments  •  Being  suited  to  projects  where  the  requirements  are  vola@le  or  poorly   understood.  Itera@ons  of  discovery  drive  the  refinement  process.  •  Making  it  easier  to  es@mate  development  effort  
  • Limita@ons  
  • Limita@ons  Some  of  the  limita@ons  of  user  stories  in  agile  methodologies:  •  They  can  be  difficult  to  scale  to  large  projects  •  They  are  regarded  as  conversa@on  starters  
  •   openware  Stefano  Leli   Fabio  Armani   stefano.leli@gmail.com armani.fabio@gmail.com @sleli @fabioarmani