Composing User Stories - Beginners Guide


Published on

Beginners Guide to Composing User Stories

Published in: Engineering, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Composing User Stories - Beginners Guide

  1. 1. Composing  User  Stories   Raja  .  S   July  2014  
  2. 2. We  Are  Here  !!!   Implementa2on   Story  Refinement   Coding   Tes2ng   Planning   Storytelling   Chartering   Project  happen  in  a  context,  created  by  their  charter   Once  you  have  some  stories,  you  can  plan   with  them   Storytelling,  the  art  of  composing  user  stories,  is  the   focus  of  this  album   Implementa2on  involves  some  story-­‐related  acIviIes  in   refinement  and  tes2ng.  We’ll  touch   on  them  slightly,  but  they’re  mostly  out  of  scope   for  this  album   This  drawing  is  linear,  but  real  projects  move  more  freely   among  these  acIviIes  
  3. 3. What  is  in  a  ChaMer  ?   A  Project’s  Charter  Drives  the  Stories  You  will  Create.   Whether  formal  or  informal,  a  charter  establishes  clear  expecta2ons  between  a   sponsor  and  a  team   The  charter  answers  key  quesIons  that  set  the  context:   •  Vision:  The  ulImate  end-­‐state  that  will  saIsfy  the  sponsor   •  Mission:  The  way  in  which  we  propose  to  accomplish  the  vision   •  Principles:  What  values  guide  the  team’s  behavior?   •  Objec2ves:  What  are  the  measurable  ,  external  outcomes  for  which  the   sponsor  is  funding  the  project.  What  tests  will  tell  us  if  those  objecIves  were   met?   •  Boundaries:  What  is  the  project  responsible  for?  What  comes  in  or  goes  out?   What  are  the  key  events?   •  CommiLed  Resources:  What  resources  will  be  made  available  to   the  team?   •  Authorizing  Players:  Who  is  sponsoring  the  work?  Who  will  judge  it?  
  4. 4. Telling  Stories   with  the   Product  Backlog  
  5. 5. Requirements  =  CommunicaIon  Tool   •  Can  be  well  thought  through,  reviewed  and  edited   •  Provide  a  permanent  record   •  Are  easily  shared  with  groups  of  people   •  Time  consuming  to  produce     •  May  be  less  relevant  or  superseded  over  Ime   •  Can  be  easily  misinterpreted   WriLen  Requirements     •  Instantaneous  feedback  and  clarificaIon   •  InformaIon-­‐packed  exchange   •  Easier  to  clarify  and  gain  common  understanding   •  Easily  adapted  to  any  new  informaIon  known  at  the  Ime   •  Can  spark  ideas  about  problems  and  opportuniIes   Verbal  Requirements  
  6. 6. User  Stories   Seek  to  Combine  the  Strengths  of  WriLen  and  Verbal  Communica2on,   Where  Possible  Supported  by  a  Picture.   *  Kent  Beck  Coined  the  Term  User  Stories  in  Extreme  Programming  Explained  1st  EdiIon,  1999.  
  7. 7. What  is  a  User  Story?   A  concise,  wriLen  descrip2on  of  a  piece  of  func2onality  that  will  be  valuable  to  a   user  (or  owner)  of  the  soTware   Stories  are:   •  User’s  needs   •  Product  descripIons   •  Planning  items   •  Tokens  for  a  conversaIon   •  Mechanisms  for  deferring  conversaIon  
  8. 8. User  Story  –  Ambiguity   Yes,  it  is.  You’ll  hear  “User  Story”  (or  “story”)  used  to  talk  about  at  least  three  things:   •  The  feature  itself  (whether  implemented  yet  or  not)   •  The  “headline”  wriMen  on  a  card   •  The  headline,  details,  discussions,  and  key  tests  that  together  describe  a  feature   The  context  will  tell  you  which  meaning  of  story  is  in  play.   Isn’t  the  Term   “User  Story”   Ambiguous?  
  9. 9. A  user  story  describes  a  s2mulus;  the  system  produces  results  in  response  to  that  s2mulus   •  All  stories  have  the  same  basic  structure:  Heading  (Itle)  and  details   User  Story  –  Basic  Structure   Heading   Details   User Logs in with Expired License Take user to home page Disable all links and buttons Add prominent renewal link that takes user to the Store – Ask for exact text and location
  10. 10. The  Heading:  Role–Ac2on–Context   The  “Role–Ac2on–Context”  formula  works  very  well  for  wri2ng  story  headings  that  reflect  events   and  responses:                   The  words  in  the  heading  create  and  reflect  a  domain  vocabulary:   •  The  people  using  our  system   •  How  they  can  act   •  What  they  can  act  upon   Heading  –  RAC  Style   Someone  or  something   that  sends  a  s2mulus   into  a  system  boundary   How  the  role  triggers  the   s2mulus.  Usually  as  simple   as  verb  +  object   Op2onal:  Where  or  when   the  ac2on  applies   Role   User Logs in with Expired License Ac2on   Context  
  11. 11. Good  Headings   Which  are  Good  Headings?   Which  of  the  following  fit  the  Role–Ac2on–Context  formula  (Good)  and  which  Do  Not?   Good   Bad   1.  “The  system  shall  process  Visa™  cards.”   2.  ATM  Customer:  Iden2fies  self   System:  Presents  op2ons  for  deposit,  withdrawal,  or  fast  cash   ATM  Customer:  Selects  fast  cash   etc.   3.  “Student  Schedules  a  Course”   4.  “Grading”  
  12. 12. As  a  type-­‐of-­‐user,  I  want  to  ac-on  so  that  business-­‐goal   DescripIon  –  Connextra  Style   User  stories  replace  detailed  requirements  and  specificaIons  with  just  enough   detail.  Just  enough  for  what?  For  esImaIng,  planning,  understanding,  discovering,   and  evolving  the  system,  and  basically,  moving  forward   The  details  elaborate  on  the  heading.  They  describe  the  sImulus,  the  response,   and  any  specifics  that  maMer  to  the  customer.  The  details  shouldn’t  be  technical,   nor  should  they  spell  out  development  tasks  or  guide  implementaIon   The  Details  Elaborate  on  the  Heading   You  can  use  any  simple  means  to  write  the  details,  as  long  as  you  get  your   point  across:   •  A  few  phrases   •  Bullet  points   •  Diagrams   •  Hand-­‐drawn  pictures   “Wri2ng  the  Stories  is  Not  the  Point,  Communica2ng  is  the  Point”   –  Kent  Beck  and  Mar-n  Fowler  
  13. 13. When  Do  We  Get  the  Details   •  During  planning  sessions   •  Even  deeper  conversaIons  about  other  details  as  they  begin  to   implement  the  story   •  Decisions,  details,  and  specificaIons  can  be  captured  in  automated   tests,  as  a  picture,  on  a  whiteboard,  or  by  any  other  useful  means   •  Key  Principle:  "Defer  decisions  unIl  the  last  responsible  moment.”  
  14. 14. Pre-­‐requisites   Some  details  are   clearly  needed   earlier  than  others.  
  15. 15. Summary   User  Stories  Provide  a  Lightweight  Way  to  Manage  Requirements.   •  “A  user  story  is  a  chunk  of  funcIonality  (some  people  use  the  word   feature)  that  is  of  value  to  the  customer.”   •  A  story  card  consists  of  a  heading  (Itle)  and  details   •  The  formula  Role–AcIon–Context  can  help  you  write  effecIve   story  headings   •  A  story  is  useful  even  before  we  work  out  its  details:  “A  user  story  is   a  promissory  note  for  a  conversaIon.”  (Cockburn)   •  “CCC:  Card,  ConversaIon,  ConfirmaIon”  (Jeffries)  
  16. 16. What  Makes  a  User  Story  Good   A  Story  Should  be   •  Understandable  to  customers  and  developers   •  Testable   •  Valuable  to  the  customer   •  Small  enough  so  that  the  programmers  can  build  half  a  dozen  in   an  iteraIon   –  Kent  Beck  and  Mar-n  Fowler  
  17. 17. INVEST  –  Acronym   Bill  Wake  devised  the  acronym  INVEST  as  a  reminder  of  the  properIes  of  good  stories   Independent   Nego2able  (and  Nego2ated)   Valuable   Es2matable   Small   Testable   Stories  ideally  describe  non-­‐overlapping  bits  of  funcIonality,  possible  to  implement  in  any  order   The  customer,  developers,  and  testers  can  agree  on  what  the  story  means  precisely  enough  that  tests  can  be  created   Stories  have  flexibility;  there’s  room  for  a  collaboraIve  definiIon  of  success   Stories’  value  makes  sense  from  a  customer  or  end  user’s  perspecIve.  They’re  not  described  in  terms  of  a  developer’s  tasks   The  team  can  esImate  the  difficulty  of  the  story  (at  least  to  a  rough  level)   The  story  is  small  enough  for  its  purpose.  For  implementaIon,  it  can  be  completed  in  less  than  an  iteraIon.   For  longer  term  planning,  the  story  is  larger  
  18. 18. What  Characterizes  Great  User  Story   Essen2al   The  user  story  describes  something  that  helps  achieve  essenIal  management  objecIves   External   The  user  story  perspecIve  views  the  system  as  a  black  box,  describing  what  is  to  happen,   not  how  it  happens   Instantaneous   The  user  story  happens  at  an  instant  in  Ime  rather  than  over  a  duraIon  of  Ime   Detectable   The  user  story  has  an  explicit  sImulus  (acIon-­‐  or  Ime-­‐based)  
  19. 19. EssenIal  Stories   •  Essen2al  user  stories  provide  value  to  sponsors   •  What  provides  value?  SoTware  that  helps  achieve  a  project  charter's  vision,  mission,   or  key  objec2ves   •  Sponsors  ul2mately  care  about  effects,  the  changes  in  the  outside  world  resul2ng  from   the  system   •  Here  is  the  vision  statement  project  charter:   §  Rapidly  spawned,  knowledge  workers,  skilled  in  the  fundamentals  of  collaboraIve  learning   §  User  stories  that  contribute  to  achieving  this  vision  are  essenIal.  Thus,  knowledge  workers   adds  eIqueMes  of  collaboraIon  in  enterprise  to  his  learning  plan  is  essenIal  because  it  lets   Knowledge  workers  teach  themselves     §  The  story  knowledge  workers  adds  eIqueMes  of  poetry  learning  to  his  learning  plan  is  not   essenIal  to  the  vision.  In  other  words,  it  is  not  currently  something  valued  by  sponsors  
  20. 20. External  Stories   •  User  stories  that  are  external  to  a  system  boundary  focus  on  organiza2onal  and  business   concerns  rather  than  technical  ones   •  The  user  story  perspec2ve  views  the  system  as  a  black  box,  describing  what  is  to  happen,  not   how  it  happens  within  the  black  box   •  The  external,  organiza2onally-­‐focused  language  of  user  stories  survives  changes  in  technology;   how  a  user  story  gets  implemented  is  up  to  the  programmers   •  A  given  user  story  might  have  hundreds  of  ways  it  could  be  implemented   •  When  wri2ng  User  Stories,  don't  include  any  technological  assump2ons  about  how  the  story   "should"  be  implemented   •  User  stories  reflect  end-­‐to-­‐end  func2onality  
  21. 21. Instantaneous  Stories   A  Great  Story  Describes  an  Instantaneous  Event.   The  story’s  ac2on  or  event,  happens  at  an  instant  in  2me  rather  than  over  a   dura-on  of  2me   The  phrase  “Clock  hands  move  around  clock  face”  fails  this  criterion  because  there   is  no  single  instant  in  2me  during  which  that  happens   The  clock’s  hands  reaching  a  certain  posi2on  or  2me  would  be  an  instantaneous   event   These  stories  headings  are  examples  of  instantaneous  events   •  System  sends  daily  summary  email   •  Customer  selects  report  
  22. 22. User  stories  are  triggered  by  something  –  and  that  trigger  must  be  detectable  by   the  system     Ed  Yourdon  (author  of  the  classic,  modern  structured  analysis)   describes  three  types  of  event  triggers:   •  Flow-­‐oriented  Events:  Triggered  by  data  arriving;  the  most  common  sort   Example:  Customer  cancels  order.   •  Temporal  Events:  Triggered  by  a  point  in  Ime.   Example:  System  processes  credit  cards  at  9:00PM   •  Control  Events:  Triggered  by  external  sImulus;  common  in  real-­‐Ime  systems   Example:  Alarm  sensor  signals  door  open   Detectable  Stories  
  23. 23. Quiz   External  Stories  Quiz   Please  drag  the  boxes  to  re-­‐order  them  from  best  to  worst,  in  terms  of  their  taking  an  external  perspecIve  of  the  system.   Place  these  in  the  correct  order:   Student  Reveals  Answers   Student  Reveals  Answers  via  JavaScript   Student  Clicks  “Show  Answers”   Student  Reveals  Answers  by  Joining  Quiz  Answer  Column  in  Quiz  Table  with  Quiz  QuesIon  Table   Instantaneous  Stories  Quiz   For  each  item,  tell  whether  it  takes  place  at  an  Instant  or  over  a  Dura2on  of  Ime.   We  prefer  stories  with  s2muli  that  are  instantaneous,  rather  than  occurring  over  a  period  of  2me.   1.  Taxpayer  Submits  Tax  Form   2.  Admin  Reads  Report   3.  Device  Monitors  Blood  Pressure   4.  User  Selects  Context-­‐SensiIve  Help   Instant   Dura2on   Can  You  Hear  Me  Now?   Which  events  are  detectable?  For  each  event,  please  tell  whether  it  is  Detectable  or  Not.   1.  System  is  to  send  a  warning  noIce  3  days  before  library  book  is  due   2.  User  presses  keyboard  key(s)  to  capture  contents  of  the  screen   3.  Elevator  passenger  imagines  going  to  the  12th  floor   4.  The  developer  runs  into  the  project  manager  in  the  hallway  and  tells  her  that  the  task  is  completed   5.  The  government’s  tax  department  has  flagged  your  tax  return  and  is  considering  whether  to  audit  you.          (This  is  from  the  perspecIve  of  the  taxpayer,  not  the  government)   Detectable   Not  
  24. 24. •  First,  the  mere  existence  of  the  story  implies  that  the  project  community  considers  it  important.   Stories  that  actually  get  implemented  are  (hopefully)  essen2al.  If  you  don’t  need  the  story,  get   rid  of  it.  (If  you  track  stories  on  cards,  you’ll  get  a  saIsfying  feeling  when  you  r-­‐r-­‐rip  it  up)   •  If  you  model  the  system’s  interacIons  properly,  the  role  is  usually  an  external  enIty  (user,   accountant,  another  system)  sending  a  sImulus  into  the  system   •  Instantaneous  events  manifest  themselves  in  the  acIon,  usually  through  the  choice  of  the  verb   •  When  the  means  of  interacIng  with  the  system  are  clear,  such  as  a  buMon-­‐click  or  API  call,  the   acIon  describes  a  detectable  event   •  A  proper  context  helps  to  pinpoint  all  the  criteria,  and  helps  us  to  write  beMer  stories   Four  Criteria's  and  RCA  Format   I’m  not  sure  I  understand  how   these  four  criteria  relate  to  the   Role–Ac2on–Context  structure  
  25. 25. Summary     The  Four  Criteria:  Essen2al,  External,  Instantaneous,  and  Detectable   Can  Help  Keep  Your  Stories  on  Track   1   Essen2al:  Valuable  to  sponsors  (as  part  of  the  charter)   2   External:  Takes  an  outside-­‐the-­‐system  perspecIve   3   Instantaneous:  Happens  at  a  moment  in  Ime,  not  over  an  interval  of  Ime   4   Detectable:  The  system  has  a  way  to  tell  that  the  story  is  triggered  
  26. 26. What  are  Roles   When  we  say  User,  we’re  usually  talking  about  an  individual,  a  person   A  role  is  an  abstracIon:  A  name  for  how  a  parIcular  group  of  people   use  the  system   The  name  “role”  comes  from  theater:  An  actor  plays  a  role  by  acIng   like  someone,  but  they  don’t  really  become  that  person   Even  more  common,  a  single  role  can  be  filled  by  different  people:  Many  people   are  Shoppers   A  system  may  enforce  roles  (eg.,  only  Administrators  can  install  soqware),  but  we  don’t  require  that   Roles  need  not  be  explicit  in  the  system:  We  can  be  a  Browser  and  a  Shopper,   without  any  need  for  the  system  to  keep  track  of  which  role  we’re  playing   One  person  can  have  mul2ple  roles:  A  person  may  be  acIng  like  a  Browser  and  a  Shopper  at   different  Imes  in  a  single  session   Roles  Iden2fy  PaLerns  of  Using  the  System  
  27. 27. Search  Widely  for  Roles   Roles  help  us  create  higher-­‐value  systems  by  focusing  on   the  needs  of  par2cular  groups  of  users   A  brainstorming  and  refinement  process  can   help  us  iden2fy  roles  (from  So6ware  for  Use   by  Constan2ne  and  Lockwood):   •  Compile  –  Brainstorm  or  otherwise  generate  as  many   candidates  as  possible   •  Organize  –  Review  and  sort  them;  understand  their   relaIonships;  consolidate  them   •  Detail  –  Fill  in  any  missing  data   •  Refine  –  Improve  and  complete  the  model   Develop  an  Ini2al  Model  of  Roles  and  Their  Rela2onships.  
  28. 28. Characters  of  Users   Knowledge  about  users  can  help  iden2fy  missing  roles  and  guide  us  in  how  we  use  roles   Categories  of  users  can  suggest  missing  roles,  and  guide  us  in  how  we  treat  roles  we   know  about   Roles   Characteris2cs   Primary   or   Secondary   Do  we  need  to  address  this  user’s  needs  sooner  or  can  we  wait  Ill  later?   Example:  Customer  is  a  primary  role  for  the  vacaIon  site;  customers  bring  in  money  so   we  want  to  support  them  early   Favored   or   Disfavored   Are  we  trying  to  help  this  user  or  avoid  helping  them?   Example:  A  compeItor  is  a  disfavored  user;  we  might  add  watermarks  to  our  pictures  t   make  it  harder  for  compeItors  to  steal  them   Direct   or   Indirect   Does  this  user  operate  they  system  themselves  or  does  somebody  else  use  the  system   on  their  behalf?   Example:  Customer  is  a  direct  user,  while  a  Giq  Recipient  is  an  indirect  user  
  29. 29. Primary  or  Secondary   Think  about;  which  roles  are  Primary  and  which  are  Secondary?   Primary Secondary 1.  Marke2ng  Manager:  All  the  markeIng  manager  wants  is  that  within  six  months  of   iniIal  release,  markeIng  starts  receiving  reports  monthly  reports  on  the   effecIveness  of  adverIsing  campaigns   2.  Vaca2on  Creator:  A  member  of  the  markeIng  department  who  creates  a  vacaIon   by  uploading  a  set  of  compaIble  photographs   3.  Hacker:  On  Day  1,  some  hackers  will  try  to  score  a  free  vacaIon  by  looking  for  bugs   in  the  checkout  process  
  30. 30. Favored  or  Disfavored   For;  which  stakeholders  are  Favored  and  which  are  Disfavored?   Favored Disfavored 1.  Purchaser  of  a  vaca2on   2.  Travelocity   3.  Our  photography  partner   4.  M4dd06h4x0r  (a  hacker)  
  31. 31. Oqen  ForgoMen  Role   You  Won’t  Support  Every  Stakeholder,   But  Look  for  Key  Roles  Beyond  The  Obvious  Users.   Certain  roles  are  easy  to  forget  because  they’re  oqen   not  everyday  users  of  the  system,  but  they  an   important  impact  on  the  acceptability  of  the  system   as  a  whole:   •  Administrators   •  Operators   •  Supervisors   •  ExecuIves   •  Auditors   •  Hackers  and  other  disfavored  users  
  32. 32. Dig  Deeper   Deeper  Knowledge  about  Users  Can  Suggest   Useful  Dis2nc2ons  in  Roles.   Understanding  these  characterisIcs  will  be  especially  helpful  in  designing  the  interface. For  the  people  in  the  roles  you  iden2fy:   •  What  are  their  goals?   •  What  is  their  domain  exper2se?   •  What  is  their  technology  exper2se?   •  How  oTen  will  they  use  the  system?   •  What  else  is  important  about  them?  
  33. 33. How  to  Start?   Refine,  Revise,   Redistribute   Review  with   Project  Community   DraT  Stories   Use  in  Planning   Suppose  you’re  just  star2ng  to  write   stories.  How  and  where  do  you  start?   The  following  process  is  oTen  useful:     Does  this  look  familiar?   It’s  a  straighoorward  interpreta2on  of   a  standard  Agile  approach:                 So  get  a  pen,  a  bunch  of  3”  x  5”   index  cards  or  a  whiteboard,   and  start  wri2ng!     Start  small  and   g  r  a  d  u  a  l  l  y   improve  your   work.  
  34. 34. This  Sequence  of  Steps  Can  Help  You  Focus  Your  Story  Wri2ng.   A  Procedure  for  Story  Telling   1. Pick  any  area  of  the  product,  or  any  idea  from  your  charter.   2. Iden-fy  the  main  actor  (role),  or  some  leading  actor   •  What  would  this  person  do?   •  What  does  this  person  care  about?   •  Ignoring  the  users  interface,  what  does  this  person  try  to  achieve?   Turn  the  answers  into  stories:  Role,  Ac2on,  Context   3.  Does  a  story  depend  on  another,  unwriLen  story?   Write  that  story.  (We  prefer  independent  stories,  but  not  at  the  cost   of  missing  stories)   4.  Is  there  some  overlap  between  stories?   No  worries.  Ideally,  you  can  redistribute  their  purpose   (to  make  them  independent);  if  not,  keep  them  as  is.  
  35. 35. Being  Adventurous   Gather  a  group  of  people  and  brainstorm.  What  do  you  absolutely  have  to  do  to   accomplish  the  project’s  mission?  (psst:  Try  this  without  the  developers  in  the  room,   to  increase  the  focus  on  the  business  need)   Something  doesn’t  feel  right?  Tear  up  some  cards  for  good  measure   If  you  write  a  “wishful  thinking”  story:  What  would  the  soqware  have  to  support   before  that  story  could  ever  be  considered?   That’s  another  set  of  stories   Ignore  the  plan,  write  everything  down   Browse  the  table  of  contents  or  top-­‐level  headings  of  an  exisIng  spec,  recasIng  the   funcIonality  as  stories  
  36. 36. Tips   •  Review  your  charter  and/or  mission;  have  you  missed  anything  needed  to  support  it?   •  Consider  the  project  community  –  users  and  stakeholders;  are  there  users  or  needs   you  haven’t  addressed?   •  Review  what  you’ve  done  with  someone  else   •  Look  at  your  domain  vocabulary.  Stories  you’ve  already  wriMen  will  have  people   (roles),  acIons,  and  objects.  Are  there  combinaIons  that  suggest  a  new  story   you  need?   •  Shuffle  your  stories  in  various  ways:  By  role,  by  when  it  happens,  by  priority,  by   esImate.  Does  this  suggest  any  stories?   •  Move  on.  If  you’re  not  used  to  wriIng  stories,  you  may  be  surprised  by  how  few  high-­‐ level  stories  you  need.  Maybe  it’s  Ime  to  move  on  to  stories  that  will  be  implemented   soon,  working  out  details  such  as  business  rules  or  tests   If  You  Get  Stuck  While  Wri2ng  Stories,  Try  These  Ideas:  
  37. 37. Access  Your  SoluIon   •  Did  you  cover  the  most  important  interac2ons?   •  Is  each  user-­‐triggered  story  an  end-­‐to-­‐end,  user-­‐level  task?  (This  is  someImes  known   as  the  “Coffee  Break  Rule”:  Would  the  user  feel  like  it’s  a  good  Ime  to  take  a  coffee   break  aqer  compleIng  this  task?)   •  Do  your  story  headings  follow  the  Role–Ac2on–Context  format?   •  Are  your  headings  short  (typically  five  or  fewer  words,  rarely  if  ever  ten  words)?   •  Are  your  headings  technology-­‐  and  [user]  interface-­‐independent?   •  Are  you  seeing  a  domain-­‐level  vocabulary  emerge?  
  38. 38. Summary   •  There  are  a  variety  of  ways  to  organize  your  story  wri2ng.   Think  about  your  charter,  about  product  areas,  about  roles,   acIons,  and  contexts   •  You’ve  pracIced  wriIng  stories  in  the  Role–Ac2on–Context  format   •  You  can  use  the  self-­‐assessment  quesIons  to  help  you  asses  stories   in  live  projects  
  39. 39. SECOND  BATCH  (REST  27  SLIDES)  
  40. 40. System  and  Boundary   Consider  the  soTware  owned  and  run  by  a  small  doctor’s  office  to  manage  its   appointments,  medical  records,  and  insurance  claims.   Which  of  the  following  are  Inside  the  system  boundary  and  which  are  Outside?   Inside   Outside   1.  Recep2onist  (who  schedules  appointments)   2.  Database  (on  which  appointments  and   medical  records  are  stored)   3.  Insurance  Claims  System  (to  which  our  system  transmits   claims  via  a  standard  protocol)   4.  The  Internet  (over  which  encrypted  informa2on  is  sent)  
  41. 41. CCL  –  Pillar,  System  and  Boundary  
  42. 42. Requirements  Always  Emerge   It  is  impossible  to  know  all  requirements  in  advance   “Thinking  harder”  and  “thinking  longer”  can  uncover  some  requirements,  but   Emergent  requirements  are  those  are  users  cannot  iden2fy  in  advance   Every  project  has  some  emergent  requirements  
  43. 43. So  What  Do  We  Do?   •  We  Talk  More,  Write  Less   –  But  write  some  if  you  need  to   •  Show  SoTware  to  Users   •  Acknowledge  that  Requirements  Emerge   –  And  all  that  this  implies   •  Progressively  Refine  Our  Understanding  of  the  Product   –  And  express  this  progressive  refinement  in  the  product  backlog  
  44. 44. Stories  Make  Great  Backlog  Items   Card   •  Stories  are  tradiIonally  wriMen   on  note  cards   •  May  be  annotated  with  notes,   esImates,  etc.   Conversa2on   •  Details  behind  the  story  come   out  during  conversaIons  with   product  owner   Confirma2on   •  Acceptance  tests  confirm  the   story  was  coded  correctly  
  45. 45. Beat  the  System   There’s  usually  a  beLer  role  name  than  “The  System.”   You  may  be  tempted  to  have  a  role  “The   System,”  e.g.,  System  Generates  Daily  Summary   Report   Instead,  try  describing  the  human  who  makes   use  of  what  the  system  does:  Supervisor  Selects   Daily  Summary  Report.  It’s  even  beMer  if  you  can   idenIfy  what  the  human  is  going  to  do  with  the   result:  Supervisor  Adjusts  Schedule   Moving  from  the  domain  of  informaIon   processed  in  the  user’s  head  back  to  user  acIons   can  help  us  focus  beMer  on  the  user’s  true  needs   (Don’t  force  it,  though  –  “The  System”  may  be   the  most  expressive  name)  
  46. 46. Humans  Only  !!!   A  role  can  correspond  to  a  human  or  an  automated  system.   Should  roles  be  filled  only  by  humans,  or  can  we  name   automated  systems?   Roles  can  be  either:   •  We  like  the  role  to  menIon  the  human  when  the  human  feels   like  they’re  interacIng  with  the  system  (even  if  that  interacIon   is  through  another  system  such  as  a  web  browser)   •  But  consider  the  system  boundary  (context  diagram);  if  an   automated  system  connects  to  our  system,  it’s  fine  to  name  that   system  as  the  role   •  For  example,  out  pet  sales  system  “talks”  to  the  bank’s   automated  credit  card  processing  system,  so  Credit  Card   Processor  would  be  a  fine  role  name  
  47. 47. Summary   •  Roles  iden2fy  paLerns  of  usage;  different  roles  interact   differently  with  the  system   •  Don’t  forget  important  roles  such  as  operators,   administrators,  and  auditors   •  Deepen  your  understanding  of  the  user  by  considering   their  goals,  domain  and  technology  experIse,  and   frequency  of  use   •  Use  adjec2ves  to  succinctly  idenIfy  roles   (Go  beyond  User)   •  Rather  than  using  System  as  a  role,  try  to  iden2fy  who  acts   and  who  benefits  
  48. 48. Where  are  the  Details   Process  mapping,  sketching,  and  storytes-ng  help  define  a  story’s  details.   The  heart  of  a  story  is  the  high-­‐level  funcIonality  captured  in  the   headline,  but  that  doesn’t  define  funcIonality  enough  to  just  go   implement  it   Implementa2on  requires  detailed  decisions  about  how  the  feature   will  work,  and  how  we’ll  know  it’s  done   User  stories  don’t  come  with  a  built-­‐in  method  for  these  decisions:   Every  team  is  different,  and  there  are  many  approaches   We’ll  briefly  explore  three  techniques  that  many  teams  have  found   helpful:  Process  Mapping,  Sketching,  and  Storytes2ng  
  49. 49. Process  Mapping:  Follow  the  Object   •  Triggers,  pulses,  and  audio  are  the  key  objects   •  This  map  shows  how  a  trigger  goes  to  a  sound  generator,  and  its  audio  goes  to  a  mixer;  the  drum   clock  generates  a  pulse  that  goes  through  a  paMern  sequencer  that  drives  drum  audio,  which   goes  to  its  own  volume  control  and  the  mixer;  then  all  audio  goes  to  a  master  volume  control   and  out  to  a  speaker   •  One  way  to  figure  out  should  happen  is  to  follow  the   object;  track  an  object  as  it  moves  through  –  and  is   transformed  by  –  the  system   •  Consider  an  electronic  keyboard  with  a  built-­‐in  rhythm   secIon  where  you  can  set  the  drummer  up  with  a  loud   bossa  nova,  then  play  your  tune  on  the  keyboard   What  do  we  find  when  we  map   the  objects?  
  50. 50. Triggers,  pulses,  and  audio  are  the  key  objects   This  map  shows  how  a  trigger  goes  to  a  sound  generator,  and  its  audio  goes  to  a  mixer;  the  drum   clock  generates  a  pulse  that  goes  through  a  paMern  sequencer  that  drives  drum  audio,  which  goes   to  its  own  volume  control  and  the  mixer;  then  all  audio  goes  to  a  master  volume  control  and  out  to   a  speaker                   Modern  keyboards  work  more  in  the  digital  domain,  but  that’s  irrelevant  to  the  main  point;  in   process  mapping  we  idenIfy  (and  devise)  the  moIon  and  transformaIon  of  objects  in  the  system   Follow  an  objet  to  find  its  movement  through  &  transforma2on  by  the  system.   Keyboard   Sound  Generator   Clock   Drum  Sound  Generator   PaLern  Sequencer   Rhythm  Volume   Mixer   Overall  Volume   Trigger   Audio   Pulse   Audio   Trigger   Audio   Audio   Audio   Speaker  (Audible  Sound)  
  51. 51. Watch  the  People   Watching  people  gives  a  different  perspec2ve  on  the   value  stream  (compared  to  focusing  on  key  objects  such   as  transacIons).   Focusing  on  people  lets  you  ask  them  several  key  quesIons:   1.  What  do  you  do  in  the  normal  case?  (This  may  reveal  places   the  system  can  ease  or  eliminate  work)   2.  Are  these  special  cases  or  excep2ons  that  are  handled   differently?  How  do  they  work?  (This  may  reveal  process   flows  you  didn’t  know  about)   3.   What  else  do  you  do?  (This  may  reveal  key  objects  and   opportuniIes  you  weren’t  aware  of)   Objects  usually  carry  the  value,   but  people  give  you  key  insights.   A  map  of  the  flow  of  items  and  the  processes  that  work  with   them  can  be  a  very  useful  tool.  
  52. 52. Remembrance  of  Things  Past   Data-­‐intensive  systems  require  details  about  where  to  find  and  store  data.   •  Objects  and  people  are  interesIng,  but  we  oqen  also   need  to  map  the  data  that’s  been  remembered  by   the  system   •  For  data-­‐intensive  systems,  working  out  where  to   find  data  is  a  key  challenge   •  Some  feeds,  databases,  and  so  on  are  outside  and   others  inside  the  system  boundary.  As  usual,  our   context  maMers   •  The  level  of  detail  depends  on  the  stage   •  In  early  planning,  it’s  enough  to  know  “We  can  get   that  data  somewhere.”  For  implementaIon,  we   need  details  about  where  the  data  is  and  the   transformaIons  it  needs  
  53. 53. StorytesIng   Storytests  help  create  the  meaning  of  a  story.   Storytests  are  tests  in  the  language  of  the  domain,  wriMen  to   clarify  a  story   They  aren’t  meant  to  be  exhausIve  but  to  communicate  a   story’s  essence   ImplementaIon  requires  details,  but  less  is  needed  to   understand  and  esImate  stories   Tests  are  not  ripe  apples  on  a  tree,  waiIng  to  be  plucked   and  used;  rather,  creaIng  tests  helps  create  the  meaning  of   the  story   What  do  we  do  with  storytests?  Concrete  examples  are   great  for  helping  discuss  stories,  and  are  prime  candidates   for  automaIon  
  54. 54. Best  Ideas   Where  do  you  get  your  best  ideas  for  func2onality?   (Your  opinion;  there’s  no  single  right  answer)   Building  models  of  users  and/or  ac2vi2es   Watching  users  in  ac2on  (doing  their  work)   Brainstorming,  alone  or  with  others   Listening  to  what  users  tell  us  they  need  
  55. 55. Layout  Overall  System   As  you  proceed,  your  pile  of  stories  will  grow  and   you’ll  rip  up  some  stories   It  helps  to  organize  the  cards  according  to  some   criterion   •  Theme   •  Category   •  Flow   •  NavigaIon   •  EvoluIonary  Path   •  Release  or  IteraIon   WriIng  headings  according  to  the  Role-­‐Ac2on-­‐ Context  formula  helps  a  lot  here   You  can  also  use  paper  mockups  of  screens  and  flow   Organize  your  stories  to   reveal  the  big  picture   The  example  on  the  right  shows  how  a  user  would   navigate  in  the  new  applicaIon  
  56. 56. Priori2zing  the   Product  Backlog  
  57. 57. The  Product  Backlog  Iceberg   A  descripIon  of  desired   funcIonality  told  from  the   perspecIve  of  the  user  or   customer   User  Story   A  large  user  story   Epic   A  collecIon  of  related   user  stories   Theme  
  58. 58. How  Much  Detail?   Process   Fixed   Input   Must  be  described  in  just   enough  detail  to  be  turned  into   the  output  by  the  process   Output   Fixed   Just-­‐in-­‐2me   just-­‐enough  
  59. 59. What  Makes  a  Good  Story?   Independent  I   Negotiable  N   Valuable  V   Estimatable  E   Sized Appropriately  S   Testable  T  
  60. 60. •  Dependencies  lead  to  problems  esImaIng  and  prioriIzing   •  Can  ideally  select  a  story  to  work  on  without  pulling  in  18  other  stories   Independent   •  Stories  are  not  contracts   •  Leave  or  imply  some  flexibility   Nego2able   •  To  users  or  customers,  not  developers   •  Rewrite  developer  stories  to  reflect  value  to  users  or  customers   Valuable   •  Because  plans  are  based  on  user  stories,  we  need  to  be  able  to  esImate  them   Es2matable   •  Small  enough  to  complete  in  one  sprint  if  you’re  about  to  work  on  it   •  Bigger  if  further  off  on  the  horizon   Sized  Appropriately   •  Testable  so  that  you  have  a  easy,  binary  way  of  knowing  whether  a  story  is  finished   •  Done  or  not  done;  no  “parIally  finished”  or  “done  except”   Testable   I   N   V   E   S   T  
  61. 61. PrioriIzing  the  Product  Backlog   Three  Steps   Organize   Needs  into   Themes   Priori2ze   Themes   Assess   Importance  of   Each  Theme   1   2   3  
  62. 62. Why  Themes?   OTen  Individual  Stories  Cannot  be  Priori2zed  Against  Each  Other   •  The  ‘A’  key  or  the  ‘E’  key?   •  Tables  or  Undo?   •  The  leq  front  wheel  or  the  right  front  wheel?   •  Increased  leg  room  or  a  larger  engine?   What’s  More  Important   in  a  Word  Processor?   What’s  More  Important   on  a  Car?   1   2  
  63. 63. Eliminate  redundant  stories   Write  each  story  on  its  own   note  card  or  post-­‐it   Label  each  group  with  a  theme  name   Group  similar  stories   Review  the  results   If  you  have  a  lot  of  themes  or   have  small  themes,  consider  making   themes  of  themes   Steps  for  Organizing  into  Themes   If  you  started  with  a  story-­‐wri2ng  workshop,  you  may  already  have  themes.  
  64. 64. Affinity  Grouping   Distribute  cards  equally  to  all  par2cipants   •  No  parIcular  paMern  to  how  you  do  this   Someone  reads  a  card  and  places  in  on  wall  /  table   •  Others  look  for  similar  cards  and  add  them  to  it   Next  person  reads  a  card,  places  it,  and  others  place  similar  cards  with  it   Con2nue  repea2ng  un2l  out  of  cards  
  65. 65. User  Story  Template  –  1   As  a  [user  role]  I  want  to  [goal]     •  So  I  can  [reason]   •  As  a  [type  of  user]  I  want  to  [perform  some  task]   so  that  I  can  [reach  some  goal]   Example:     •  As  a  registered  user  I  want  to  log  in   •  So  I  can  access  subscriber-­‐only  content  
  66. 66. User  Story  Template  –  2   •  Who  (user  role)     •  What  (goal)   •  Why  (reason)   – Gives  clarity  as  to  why  a  feature  is  useful   – Can  influence  how  a  feature  should  funcIon   – Can  give  you  ideas  for  other  useful  features     – That  support  the  user's  goals  
  67. 67. THANK  YOU!