User Story Mapping - mini iad 2014 (Armani, Rodriguez)

1,708 views

Published on

Riteniamo, che non vi sia dubbio sul fatto le User Story (introdotte da eXtreme Programming) e il Product Backlog (definito in Scrum) rappresentino due portentosi strumenti per la gestione agile dei requisiti e delle specifiche sia funzionali che non funzionali. Ma … hanno alcuni limiti.
Ad esempio, nonostante le notevoli caratteristiche del Product Backlog, la sua unidimensionalità non consente di creare un modello dei requisiti adatto a scalare e che consenta di gestire le dipendenze che possono essere presenti tra i vari elementi che lo costituiscono.
In questo workshop presenteremo e utilizzeremo un altro potente strumento che spesso utilizziamo durante gli User Story Workshop sia in fase d’Inception, sia all’inizio di ogni nuova release di un prodotto. Si chiama “User Story Mapping”.
Ci divertiremo con voi ad utilizzarlo in una simulazione che partendo dalla Vision di un prodotto ci consentirà di mappare i bisogni di un numero selezionato di utenti su un insieme di funzionalità organizzate in una mappa.
Inoltre vedremo come sia possibile utilizzare questo strumento per gestire le diverse release di un prodotto a partire dal così detto “Walking Skeleton” fino alle successive MMF (Mininum Markatable Feature)
Sapete cos’è il modello di Kano, FURPS+, o come il nome della capitale della Russia possa essere utilizzato per assegnare priorità alle diverse storie? Se vi abbiamo incuriosito, o se pensate che avere un nuovo strumento mentale da aggiungere alla vostra cassetta degli attrezzi potrebbe esservi utile, partecipate. Sarete certamente i benvenuti.

Published in: Software, Technology, Sports

User Story Mapping - mini iad 2014 (Armani, Rodriguez)

  1. 1. Armani  -­‐  Rodriguez   May  17  2014  
  2. 2. Fabio  Armani   fabio.armani@icloud.com,  @fabioarmani     Andrea  Torino  Rodriguez   rodryz@gmail.com,  @agilerod  
  3. 3. Why   •  It  allows  you  to  see  the  big  picture  in  your   backlog.   •  It  gives  you  a  be8er  tool  for  making  decisions   about  grooming  and  priori<zing  your  backlog.     •  It  promotes  silent  brainstorming  and  a   collabora<ve  approach  to  genera<ng  your   user  stories.  
  4. 4. Why   •  It  encourages  an  itera<ve  development   approach  where  your  early  deliveries  validate   your  architecture  and  solu<on.   •  It  is  a  great  visual  alterna<ve  to  tradi<onal   project  plans.   •  It  is  a  useful  model  for  discussing  and   managing  scope.   •  Allows  you  to  visualize  dimensional  planning   and  real  op<ons  for  your  project/product.    
  5. 5. Silent  Brainstorming  
  6. 6. Silent  Brainstorming  
  7. 7. Silent  Brainstorming   •  Decide  on  the  type  of  ques<on   •  Step  1:  generate  ideas  individually.  One  idea  per  post-­‐it   •  Step  2:  read  and  put  ideas  on  the  table   •  Step  3:  group  the  ideas  (clustering)   •  Step  4:  Name  each  group   •  Step  5:  prepare  for  vo<ng   •  Step  6:  each  person  votes  for  their  top  3   •  Step  7:  facilitator  tallies  the  votes     •  Step  8:  act  on  the  item(s)  with  the  highest  vote!  
  8. 8. Dimensional  Planning  
  9. 9. Dimensional  Planning   •  In  Scrum  the  Product  Backlog  is  an  ordered  list  of   features.  Unfortunately  the  linearity  of  the  ordered  list  is   not  consistent  with  the  way  us  humans  think  about   problems.   •  Problems  even  in  the  business  space  are  mul<-­‐ dimensional.  So,  we  probably  also  should  think  of  solving   our  problems  in  mul<ple  dimensions.  This  is  where   Dimensional  Planning  comes  in  handy  when  spliXng   Product  Backlog  Items  in  your  Product  Backlog  during  the   Refinement  or  Grooming  mee<ngs.  
  10. 10. Dimensional  Planning   •  In  Scrum  the  Product  Backlog  is  an  ordered  list  of   features.  Unfortunately  the  linearity  of  the  ordered  list  is   not  consistent  with  the  way  us  humans  think  about   problems.   •  Problems  even  in  the  business  space  are  mul<-­‐ dimensional.  So,  we  probably  also  should  think  of  solving   our  problems  in  mul<ple  dimensions.   •  This  is  where  Dimensional  Planning  comes  in  handy   when  spliXng  Product  Backlog  Items  in  your  Product   Backlog  during  the  Refinement  or  Grooming  mee<ngs.  
  11. 11. Dimensional  Planning  
  12. 12. Dimensional  Planning  
  13. 13. Dimensional  Planning   From  dirt  road  to  flying  cars   •  Dirt  road   •  Cobblestone  road   •  Asphalted  road   •  Highway   •  Flying  cars  
  14. 14. Dimensional  Planning  
  15. 15. Real  Op<ons   •  How  and  when  (not)  to  make  decisions   •  Defer  commitments  
  16. 16. Problem   Customer   Supplier   Implement   Generate   op<ons   Test  and  choose   op<ons  
  17. 17. Don’t  try  to  decide  too  fast!  
  18. 18. Real  Op<ons   •  Have  a  value   •  Have  a  cost  (=  the  price  of  the  op<on)   •  Have  a  price  (“strike  price”)  when  we  exercise   the  op<on   •  Have  an  expira<on  date/condi<on   ~  “Call  Op<on”     An  op<on  is  not  an  obliga<on  
  19. 19. Grooming  
  20. 20. Living  Charter  =  Chartering  
  21. 21. How  to  create  a  User  Story  Map  
  22. 22. Group Task Group Task Task Task Group Task Task
  23. 23. Backbone  
  24. 24. Walking  Skeleton  
  25. 25. Some  defini<on   •  The  post-­‐its  you  create  in  Step  2  are  the  User  Tasks   (blue  post-­‐its  in  the  diagram).     •  The  groups  and  group  names  in  steps  3  and  4  are  the   User  Ac3vi3es  (orange  post-­‐its).  Jeff  calls  these  top   two  rows  the  backbone  and  walking  skeleton  of  your   applica<on.     •  The  user  stories  (yellow  post-­‐its)  are  organized  under   each  User  Task  in  order  of  highest  to  lowest  priority  for   that  User  Task.     •  The  chronological  order  of  how  users  will  typically  use   the  applica<on  goes  lej  to  right  (Time).    
  26. 26. How  to  priori<ze  a  User  Story  Map  
  27. 27. Story  …   Story  1   Story  2   Story  3   Sprint  N-­‐1   Sprint  N   Sprint  N+1   Story  3  
  28. 28. Story  Slicing   Story  1   Story  2   Story  3   Story  4   Story  5   Story  6   Story  7   Story  8   Story  9   Sprint  N-­‐1   Sprint  N   Sprint  N+1   Wri<ng     story  tests   Automa<ng   story  tests   Implemen<ng   the  user  story  
  29. 29. Risk  &  Assump<ons   •  Where  are  the  risky  stories?   •  Where  are  our  biggest  assump<ons?  
  30. 30. Applying  Cynefin   •  A  way  to  understand  complexity  is  that  ac<ng   in  the  space  causes  the  space  to  change,  and   cause  and  effect  can  only  be  understood  in   retrospect.  
  31. 31. Applying  Cynefin   "When  you  start  wri<ng  tests,  or  having  discussions,  and   the  requirements  begin  changing  underneath  you   because  of  what  you  discover  as  a  result,  that’s  complex.   You  can  look  back  at  what  you  end  up  with  and   understand  that  it’s  much  be8er,  but  you  can’t  come  up   with  it  to  start  with,  nor  can  you  define  what  “be8er”  will   look  like  and  try  to  reach  it.  It  emerges  as  you  work."     "...  This  is  the  land  of  high-­‐feedback,  risk  and  innova<on:   generally  stuff  you’ve  never  done  before,  anything  that   the  business  are  unsure  about,  new  technologies,  etc."  
  32. 32. Re-­‐priori3ze  o;en  
  33. 33. How  to  do  it?   1.  Divide  into  groups  of  3-­‐5  people   2.  Start  by  gathering  “things  people  do”  –  the  tasks.  Write  them   down  individually  and  then  read  them  aloud  to  your  group   –  Likely  they  start  with  a  verb.   –  These  are  high  level  user  stories  called  “Tasks”  (walking  skeleton)   –  This  forms  your  story  map  skeleton   3.  Group  them  silently  (simply  because  it  is  faster)   4.  Name  the  groups  and  lay  them  out  in  order  of  <me  (lej  to   right)   –  These  are  called  “User  Ac3vi3es”  (backbone)  
  34. 34. How  to  do  it?   5.  Add  more  detailed  user  stories  below  the  main  tasks   6.  Priori<ze  top  to  bo8om   7.  Break  into  releases   8.  Assign  values  
  35. 35. Itera<ve   1 2 3 4 5 Credit:  Jeff  Pa8on   Incremental  
  36. 36. thanks  
  37. 37. Fabio  Armani   www.open-­‐ware.org   f.armani@open-­‐ware.org,  @fabioarmani     Andrea  Torino  Rodriguez   rodryz@gmail.com,  @agilerod    

×