User Stories


Published on

A training session I did on User Stories.

Published in: Software, Technology

User Stories

  1. 1. User   Stories   Tathagat  Varma   h0p://    
  2. 2. h0p://­‐a-­‐month-­‐or-­‐less-­‐ahead-­‐is-­‐not-­‐enough/    
  3. 3. Agile  Planning  Onion   Strategy   PorFolio   Product   Release   IteraIon   Daily  
  4. 4. Product  Management  ArIfacts   IniIaIves     Epics   Themes   Sprint  Backlog   Product  Backlog   Product  Roadmap   Product  Vision   Tasks…   Stories   Scenarios  
  5. 5. Product  Vision   •  Shared  by  All   •  Desirable  and  InspiraIonal   •  Clear  and  Tangible   •  Broad  and  Engaging   •  Short  and  Sweet  
  6. 6. Product  Vision  –  Elevator  Pitch   For  (target  customer)   Who  (statement  of  the  need  or  opportunity)   The  (product  name)  is  a  (product  category)   That  (key  benefit,  compelling  reason  to  buy)   Unlike  (primary  compeIIve  alternaIve)   Our  product  (statement  of  primary  differenIaIon)   h0p://    
  7. 7. Product  Vision  Box   •  As  the  name   suggests…   •  Describes  the  top   2-­‐3  features  of   product  
  8. 8. Product  Roadmap   h0p://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/     h0p://     •  High-­‐level  plan  that   describes  how  the   product  will  evolve   •  Refers  to   •  Product  version   •  FuncIonality   •  Release  date    
  9. 9. Product  Backlog   •  A  combined  list  of  all  desired  work,  including   user  focused  stories,  technical  work,  features   &  ideas   •  Everything  is  expressed  in  User  Stories   •  List  is  prioriIzed  by  the  Product  Owner   •  Product  Owner  keeps  it  organized  with  the   team’s  help   •  Anyone  can  add  items  to  the  backlog   •  Evolves  over  Ime     •  Always  in  progress  
  10. 10. Benefits  of  Product  Roadmap   •  Helps  communicate  how  you  see  the  product  develop.   •  Helps  align  the  product  and  the  company  strategy.     •  Helps  manage  the  stakeholders  and  coordinate  the   development,  markeIng,  and  sales  acIviIes.   •  Facilitates  effecIve  porFolio  management,  as  it  helps   synchronise  the  development  efforts  of  different   products.   •  Supports  and  complements  the  product  backlog.  This   allows  the  backlog  to  focus  on  the  tacIcal  product   development  aspects.   h0p://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
  11. 11. Product  Backlog   •  The  agile  product  backlog  is  a  prioriIzed   features  list,  containing  short  descripIons   of  all  funcIonality  desired  in  the  product.     •  When  using  Scrum,  it  is  not  necessary  to   start  a  project  with  a  lengthy,  upfront   effort  to  document  all  requirements.     •  Typically,  a  Scrum  team  and  its  product   owner  begin  by  wriIng  down  everything   they  can  think  of  for  agile  backlog   prioriIzaIon.  This  agile  product  backlog  is   almost  always  more  than  enough  for  a  first   sprint.  The  Scrum  product  backlog  is  then   allowed  to  grow  and  change  as  more  is   learned  about  the  product  and  its   customers.   •  h0p:// scrum/product-­‐backlog    
  12. 12. Who  owns  Product  Backlog?   h0p://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
  13. 13. ….should  be  “DEEP”   •  Emergent  •  PrioriIzed   •  EsImated  •  Detailed   Appropriately   D   E   E  P  
  14. 14. From  Product  Roadmap  to  Product   Backlog   h0p://­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
  15. 15. Sprint  Backlog   •  User  Stories  selected   by  The  Team   •  Will  be  built  in  next   Sprint   •  Fully  EsImated   •  Divided  into  Tasks  
  16. 16. Sprint  Backlog  
  17. 17. User  Story   I as a <Role>   want <Feature>   so that <Value>
  18. 18. Why  User  Stories?   h0p://­‐content/uploads/2012/05/User-­‐Stories.jpg    
  19. 19. Why  not  ‘PRDs’?  
  20. 20. User  Story   h0p://­‐content/uploads/2012/07/post-­‐it-­‐note-­‐user-­‐story.jpg     h0ps://­‐planning-­‐poker-­‐plugin/wiki/PlanningPoker    
  21. 21. As  a  frequent  flyer,     I  want  to  be  able  to  view  current   offers  in  terms  of  mileage  points     so  that  I  can  redeem  them.  
  22. 22. Acceptance  Criteria   22   Given <System State> when <an event occurs> then <an outcome happens>
  23. 23. The  Three  C’s  of  a  User  Story   • The  story  itself   • A  promise  to  have  a  conversaIon  at  the   appropriate  Ime   Card   • The  requirements  themselves  communicated   from  the  Product  Owner  to  the  Delivery  Team  via   a  conversaIon   • Write  down  what  is  agreed  upon   ConversaIon   • The  Acceptance  Criteria  for  the  story   • How  the  Delivery  Team  will  know  they  have   completed  the  story   ConfirmaIon  
  24. 24. What  makes  a  good  User  Story?   Independent  of  all  others   NegoIable  not  a  specific  contract  for  features   Valuable  or  ver2cal   EsImable  to  a  good  approxima2on   Small  so  as  to  fit  within  an  itera2on   Testable  in  principle,  even  if  there  isn’t  a  test  for  it  yet   h0p://    
  25. 25. Scenarios,  User  Case,  User  Story   Use  Case:     Customer  walks  to  the  restaurant   Customer  enters  the  restaurant   Customer  finds  a  seat  at  the  bar   Customer  scans  the  menu   Customer  selects  a  beer   Customer  orders  selected  beer   Bartender  takes  order   Bartender  pours  beer   Bartender  delivers  beer   User  drinks  beer   User  pays  for  beer   User  Story:     A  user  wants  to  find  a  bar,  to  drink  a  beer.   h0p://­‐user-­‐stories-­‐user-­‐personas-­‐use-­‐cases-­‐whats-­‐the-­‐difference/     Scenario:     Josh  is  a  30  something  mid-­‐level  manager   for  an  ad  agency,  metro-­‐sexual  and  beer   aficionado.  He  likes  to  try  new  and  exoIc   beers  in  trendy  locaIons.  He  also  enjoys   using  a  variety  of  social  apps  on  his  smart   phone.  He  reads  a  review    on  Yelp  of  a  new   burger  &  beer  joint  downtown  with  over   100  beers  on  tap,  and  decides  to  go  walk   over  a8er  work  and  check  it  out.      
  26. 26. Themes,  Epics,  Stories,  Tasks  
  27. 27. Themes   •  We  could  put  a  rubber  band  around  that   group  of  stories  I  wrote  about  monthly   repor2ng  and  we'd  call  that  a  “theme.”   Some2mes  it's  helpful  to  think  about  a  group   of  stories  so  we  have  a  term  for  that.  S2cking   with  the  movie  analogy  above,  in  my  DVD  rack   I  have  filed  the  James  Bond  movies  together.   They  are  a  theme  or  grouping.   h0p://­‐epics-­‐and-­‐themes    
  28. 28. Themes  change/evolve…   Scrum  Product  Ownership  –  Bob  Galen  
  29. 29. Epics   •  A  Scrum  epic  is  a  large  user  story.  There's  no  magic  threshold  at   which  we  call  a  parIcular  story  an  epic.  It  just  means  “big  user   story.”  I  like  to  think  of  this  in  relaIon  to  movies.  If  I  tell  you  a   parIcular  movie  was  an  “acIon-­‐adventure  movie”  that  tells  you   something  about  the  movie.  There's  probably  some  car  chases,   probably  some  shooIng,  and  so  on.  It  tells  you  this  even  though   there  is  no  universal  definiIon  that  we've  agreed  to  follow,  and   that  an  acIon-­‐adventure  movie  must  contain  at  least  three  car   chases,  at  least  45  bullets  must  be  shot,  and  ….   •  So,  “epic”  is  just  a  label  we  apply  to  a  large  story.  Calling  a  story  an   epic  can  someImes  convey  addiIonal  meaning.  Suppose  you  ask   me  if  I  had  Ime  yesterday  to  write  the  user  stories  about  the   monthly  reporIng  part  of  the  system.  “Yes,”  I  reply,  “but  they  are   mostly  epics.”  That  tells  you  that  while  I  did  write  them,  I  didn't  get   the  chance  to  break  most  of  them  down  into  stories  that  are   probably  small  enough  to  implement  directly.   h0p://­‐epics-­‐and-­‐themes    
  30. 30. User  Stories   •  A  user  story  is  simply  something  a  user  wants.   User  stories  are  more  than  just  text  wri0en  on  an  index   card  but  for  our  purposes  here,  just  think  of  user  story  as  a   bit  of  text  saying  something  like,  “Paginate  the  monthly   sales  report”  or,  “Change  tax  calculaIons  on  invoices.”     •  Many  teams  have  learned  the  benefits  of  wriIng  user   stories  in  the  form  of:     –  As  a  <type  of  user>     –  I  <want/can/am  able  to/need  to/etc.>     –  so  that  <some  reason>.   •  But  it  is  not  necessary  that  a  user  story  be  wri0en  that  way.     h0p://­‐epics-­‐and-­‐themes    
  31. 31. Epics  -­‐>  Stories  
  32. 32. Performance  Constraint  -­‐>  Acceptance   Criteria  
  33. 33. Minimal  Marketable  Feature   •  A  Minimal  Marketable  Feature  (MMF)  is  a  feature  that  is  minimal,   because  if  it  was  any  smaller,  it  would  not  be  marketable.  A  MMF  is   marketable,  because  when  it  is  released  as  part  of  a  product,   people  would  use  (or  buy)  the  feature.   •  An  MMF  is  different  than  a  typical  User  Story  in  Scrum  or  Extreme   Programming.  Where  mulIple  User  Stories  might  be  coalesced  to   form  a  single  marketable  feature,  MMFs  are  a  li0le  bit  bigger.   O8en,  there  is  a  release  a8er  each  MMF  is  complete.   •  An  MMF  doesn’t  decompose  down  into  smaller  sub-­‐feature,  but  it   is  big  enough  to  launch  on  its  own.   •  A  MMF  can  be  represented  as  a  User  Story  —  a  short,  one-­‐sentence   descripIon.    
  34. 34. MVP,  MMF,  Stories   MVP   MMFs   User  Stories  
  35. 35. MoSCoW   •  M  -­‐  MUST:  Describes  a  requirement  that  must  be  saIsfied  in   the  final  soluIon  for  the  soluIon  to  be  considered  a  success.   •  S  -­‐  SHOULD:  Represents  a  high-­‐priority  item  that  should  be   included  in  the  soluIon  if  it  is  possible.  This  is  o8en  a  criIcal   requirement  but  one  which  can  be  saIsfied  in  other  ways  if   strictly  necessary.   •  C  -­‐  COULD:  Describes  a  requirement  which  is  considered   desirable  but  not  necessary.  This  will  be  included  if  Ime  and   resources  permit.   •  W  -­‐  WON'T:  Represents  a  requirement  that  stakeholders  have   agreed  will  not  be  implemented  in  a  given  release,  but  may  be   considered  for  the  future.  (note:  occasionally  the  word  "Won't"   is  subsItuted  for  "Would"  to  give  a  clearer  understanding  of   this  choice.  
  36. 36. Spliung  User  Stories   h0p://­‐user-­‐stories-­‐the-­‐hamburger-­‐method/    
  37. 37. 1.  IdenIfy  Tasks  
  38. 38. 2.  IdenIfy  opIons  for  tasks  
  39. 39. 3.  Combine  Results  
  40. 40. 4.  Trim  the  Hamburger  
  41. 41. 5.  Take  the  first  bite!  
  42. 42. 6.  Take  another  bite…and  conInue  
  43. 43. User  Story  Mapping  
  44. 44. 45   ©  Jeff  Pa0on,  all  rights  reserved,   The  user  story  map  contains  two   important  anatomical  features   •  The  backbone  of  the  applicaIon  is  the  list  of   essenIal  acIviIes  the  applicaIon  supports   •  The  walking  skeleton  is  the  so8ware  we  build  that   supports  the  least  number  of  necessary  tasks   across  the  full  span  of  user  experience   time necessity   The backbone The walking skeleton
  45. 45. 48   ©  Jeff  Pa0on,  all  rights  reserved,   Planning  incremental  releases  can  be   facilitated  as  a  collaboraIve  event  
  46. 46. Scenarios   •  A  usage  scenario,  or  scenario  for  short,  describes   a  real-­‐world  example  of  how  one  or  more  people   or  organizaIons  interact  with  a  system.       •  They  describe  the  steps,  events,  and/or  acIons   which  occur  during  the  interacIon.       •  Usage  scenarios  can  be  very  detailed,  indicaIng   exactly  how  someone  works  with  the  user   interface,  or  reasonably  high-­‐level  describing  the   criIcal  business  acIons  but  not  the  indicaIng   how  they’re  performed.        
  47. 47. Learning  and  Emergence  
  48. 48. EsImaIon   h0p://­‐esImaIon    
  49. 49. Use  any  measure…consistently  
  50. 50. Story  Points   •  Agile  teams  generally  prefer  to  express  esImates  in  units  other   than  the  Ime-­‐honored  "man-­‐day"  or  "man-­‐hour".  Possibly  the   most  widespread  unit  is  "story  points".   •  One  of  the  chief  reasons  is  the  use  of  velocity  for  planning   purposes.  "Velocity",  in  the  sense  Agile  teams  use  the  term,  has  no   preferred  unit  of  measurement,  it  is  a  dimensionless  quanIty.   Velocity  allows  teams  to  compute  the  expected  remaining  duraIon   of  the  project,  as  a  number  of  iteraIons,  each  iteraIon  delivering   some  amount  of  features.   •  Another  important  reason  has  to  do  with  the  social  and   psychological  aspects  of  esImaIon:  using  units  such  as  story   points,  emphasizing  relaIve  difficulty  over  absolute  duraIon,   relieves  some  of  the  tensions  that  o8en  arise  between  developers   and  managers  around  esImaIon:  for  instance,  asking  developers   for  an  esImate  then  holding  them  accountable  as  if  it  had  been  a   firm  commitment.   h0p://    
  51. 51. EsImaIon   Mainly  two  forms  of  esImaIon     –  Analogous  EsImaIon  [T-­‐Shirt  Sizing  -­‐  S,M,L,XL]   •  This  Story  is  like  another  Story  (maybe  a  li0le  more  difficult,  maybe   a  li0le  less)   •  Give  this  Story  a  comparable  esImated  value.     •  EsImate  against  mulIple  Stories  of  the  same  effort.   •  Analogous  esImaIon  is  successful  due  to  our  inherent  ability  to   be0er  measure  relaIve  size  than  absolute  size.   –  Planning  Poker   •  Each  esImator  is  given  a  deck  of  cards,  each  card  contains  a    valid     esImate.   •  Fib  ––1,2,3,5,8,13,20,301,2,3,5,8,13,20,30   •  Story  is  read  and  discussed  briefly   •  Each  esImator  selects  a  card  that  reflects  their  esImate.   •  Cards  are  turned  over  for  all  to  see.   •  Discussion  takes  place   •     Re-­‐esImate  to  try  to  get  convergence.  
  52. 52. Affinity  EsImaIng  Guidelines   Break  up  into  small  teams  of  2-­‐4   Discuss  2-­‐3  stories  so  there  is  a  sense  of  them   Find  an  iniNal  comparaNve  story   • If  team  is  already  SprinIng,  find  a  small-­‐ish  one  already  completed  that  was  a  really   good  esImate;  use  that  esImate   • Or  find  a  fully  understandable  story  and  fully  task  it  out;  call  it  either  a  2  or  a  3   Without  conversaNon,  the  enNre  team  puts  all  the  stories  on  a  big  wall   • Smallest  at  the  right  and  largest  on  the  le8  compared  to  iniIal  story   • Anyone  can  move  anyone  else’s  story  posiIon   As  acNvity  subsides,  put  a  scaled  number  line  up       SeQle  on  esNmates  for  boundary  stories  and  epics  
  53. 53. Affinity  EsImaIng   56  
  54. 54. References   •  h0p://   •  h0p://­‐+The+Longer +Story   •  h0p:// +Maturity+Model     •  h0p://­‐good-­‐user-­‐stories/     •  h0ps://     •  h0p://­‐stories   •  h0p://   •  h0p:// user_story_mapping/   •  h0p://­‐stories   •  h0p://training-­‐course-­‐ Scrum_Product_Owner