Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Death by User Stories

Jenny Martin
November 11, 2016

Death by User Stories

Death by User Stories

As an overwhelmed cross-functional team member
In order to deliver business value as early as possible
I need 6589 disembodied user stories sitting in a backlog in Jira
Like I need a hole in the head.

Do you find that once you start examining them, user stories grow and multiply until you can’t fit them in your delivery iteration? Are you drowning and struggling to see the big picture? Are you lost in user story hell and don’t know how to get out?

In this talk I’d like to introduce the OOPSI model for agile analysis. OOPSI stands for Outcome, Output, Process, Scenarios, Inputs. The OOPSI technique accelerates delivery by helping you structure your discovery activities so that you are always working on the right thing and can see the bigger picture. It will give you a narrative and context for your analysis artefacts and the examples, tests, and scenarios that support them.

If you’re using Impact Mapping, Story Mapping, Event Storming or BDD you’ll find this fits in really neatly with those activities.

Jenny Martin

November 11, 2016
Tweet

More Decks by Jenny Martin

Other Decks in Technology

Transcript

  1. Hi,  I’m  Jenny  –  I’ve  been  doing  a  lot  of  thinking  recently  about  user  stories  and  I’ve  
    been  wondering….  
     
    1  

    View Slide

  2. Are  user  stories  actually  helpful?  
    Or  are  they  doing  us  more  harm  than  good?  
    Have  we  wandered  away  from  their  intended  use?  
       
    Maybe  we’ve  wandered  so  far  away,  that  we’re  now  in  the  user  story  badlands,    
    where  the  dangerous  user  stories  live.      
     
    2  

    View Slide

  3. Let  me  paint  a  picture  of  the  badlands;  
       
    In  the  user  story  badlands  you  feel  lost  and  overwhelmed.    You  don’t  know  how  you  
    got  here  and  you  can’t  find  your  way  out.    You  don’t  know  what  you’re  doing,  you  
    don’t  have  any  documentaJon  to  turn  to,  and  your  backlog  is  so  monolithic  you  don’t  
    even  believe  it  anymore.  
       
    You’re  scared.  User  stories  are  dangerous.  
       
    But  how  do  you  protect  yourself?  
       
    Well  the  only  way  to  avoid  a  slow  and  painful  death  is  by  staying  on  the  safe  path  to  
    value.      
       
    In  this  talk  I’m  going  to  introduce  the  OOPSI  technique,  which  will  help  you  navigate  
    the  path  to  value  in  the  shortest  possible  Jmeframe  and  stay  away  from  the  
    badlands.  
       
    You  may  even  be  able  to  avoid  user  stories  altogether.    
       
    OOOOOooh  (shhhhhhhhhhh)  don’t  tell  anyone  I  said  that  
    3  

    View Slide

  4. 1    They’re  like  a  virus.    Virus’  exist  for  one  purpose  –  to  reproduce.  
       
    As  you  start  examining  them,  they  keep  on  growing  and  dividing  unJl  you  are  
    completely  consumed  by  them.  
    You  start  ‘user  story  spliVng’.      
    4  

    View Slide

  5. What  you  thought  was  a  small  user  story  grows  and  grows  unJl  you  can  no  longer  fit  
    it  in  your  delivery  iteraJon.        
       
    In  the  user  story  badlands  scope  is  creepy.  But  the  cunning  thing  about  the  creeping  
    scope  is  that  it  isn’t  actually  creeping  at  all.    It  was  always  there,  lurking  in  the  dark  –  
    you  just  hadn’t  discovered  it  yet.      
       
    You  think  that  by  wriJng  something  on  a  small  post-­‐it  note  you  can  pretend  it’s  not  
    complicated.    It’s  fine  as  long  as  you  don’t  look  at  it  for  any  length  of  Jme,  that’s  
    when  the  creeping  and  mulJplying  starts.  
     
    5  

    View Slide

  6. From  a  distance  they  all  look  the  same.      
       
    User  stories  are  disembodied  and  autonomous.    Once  you’re  surrounded  you  
    become  disorientated  and  lost,  you  can’t  see  the  big  picture  and  you  don’t  know  
    where  to  turn.    You  don’t  know  what  level  of  detail  they  are  just  by  looking  at  them.  
     
    An  Epic  looks  the  same  as  a  story.    A  detailed  story  looks  the  same  as  a  high  level  
    story.      
       
       
     
    6  

    View Slide

  7. How  can  you  tell  from  looking  at  them,  the  point  at  which  they  turn  from  a  
    requirement  into  something  that  guides  our  development?    
     
    When  does  the  thinking  happen?  
     
    It  used  to  be  easier  to  know  this  in  the  waterfall  days.    You  had  a  requirements  
    document  and  then  specificaJon  and  design  documents,  and  this  process  of  analysis  
    and  synthesis  happened  in  between.  
     
    It’s  hard  to  support  this  process  with  post-­‐it  notes  that  all  look  the  same.  
     
       
     
    7  

    View Slide

  8. Maybe  it’s  the  acceptance  criteria  that  are  supposed  to  do  that?  
     
     
    8  

    View Slide

  9. Unfortunately  Acceptance  criteria  look  like  stories  too.  
     
    I  come  from  a  tesJng  background,  and  I’ve  never  properly  understood  this.  
     
    All  the  examples  I  see  of  acceptance  criteria  wri_en  on  stories  are  just  more  
    requirements  –  at  a  lower  level  of  detail.    It’s  a  way  of  capturing  them  without  having  
    to  write  new  stories  using  the  user  story  parlance.  
       
    Acceptance  criteria  always  used  to  be  based  directly  on  the  requirements.    They  are  
    just  expressed  using  different  language.    Acceptance  criteria  are  just  requirements  
    preceeded  by  ‘verify  that’  
       
    This  just  lulls  you  into  a  false  sense  of  security,  that  you  know  how  to  test  the  thing.  
       
    This  is  dangerous.    Acceptance  criteria  aren’t  tests.    They’re  not  tests  unJl  they  are  
    concrete.    Examples  with  real  world  data  are  concrete  –  but  you  probably  won’t  
    cover  that  on  a  post  it  note.  
       
     
    9  

    View Slide

  10. You’ve  seen  the  problem  with  user  story  icebergs.    At  each  of  those  levels  of  detail,  
    there’s  always  more  under  the  surface.    An  a  lot  of  the  stuff  under  the  surface  might  
    not  be  that  important.    So  surely  we  don’t  want  to  track  the  actual  story  through  to  
    compleJon  at  any  of  those  levels,  because  we’re  going  to  iterate.  
     
     
    10  

    View Slide

  11. This  is  how  we  have  been  made  to  feel  about  documentaJon.  
    11  

    View Slide

  12. See  how  we  feel  about  post  its  though!    Happy,  Smiling!  
    12  

    View Slide

  13. DocumentaJon  –  booooo,  waste  of  Jme  
     
    13  

    View Slide

  14. PosJts  hooray!!    Happy  families!!  
     
    That’s  because  as  long  as  you  have  post  it  notes,  you’re  not  doing  too  much  
    unnecessary  documentaJon.    As  long  as  you  have  post  it  notes,  you’re  not  wasJng  
    your  Jme  
     
     
    14  

    View Slide

  15. That’s  because  as  long  as  you  have  post  it  notes,  you’re  not  doing  too  much  
    unnecessary  documentaJon.    As  long  as  you  have  post  it  notes,  you’re  not  wasJng  
    your  Jme.  
       
    But  wriJng  6756  user  stories  out  in  a  prescribed  format  –  regardless  of  how  they  are  
    supposed  to  support  our  project  a  good  use  of  Jme?  
       
    Managing  a  giganJc  backlog  of  wish-­‐list  features  that  are  out  of  date  in  a  month  and  
    no-­‐one  can  remember  is  a  good  use  of  Jme?  
       
    DuplicaJng  and  linking  and  un-­‐linking,  capturing  details  in  Jira  against  Jckets  that  are  
    effecJvely  going  to  be  binned  is  a  good  use  of  Jme?  
       
    This  all  sounds  like  job  creaJon  to  me  
       
    Where  do  you  capture  the  important  details  about  how  our  systems  will  behave?  
       
     
    15  

    View Slide

  16. You  end  up  throwing  it  all  into  Cucumber  as  tests.    And  you  move  out  of  the  user  
    story  badlands  and  straight  into  AutomaJon  Hell.    
       
    Wow  these  user  stories  are  dangerous.    So  if  they’re  so  dangerous  why  do  you  use  
    them?    
     
    16  

    View Slide

  17. So  I’d  like  you  to  turn  to  the  person  next  to  you  and  in  groups  of  2  or  3  spend  the  
    next  couple  of  minutes  answering  these  2  quesJons  &  then  we’ll  see  what  the  group  
    thinks…  
    17  

    View Slide

  18. So  I  had  the  same  conversaJon  with  myself  as  you  just  did  and  came  up  with  the  
    following  3  defining  things  about  user  stories    
     
    18  

    View Slide

  19. 19  

    View Slide

  20. 20  

    View Slide

  21. 21  

    View Slide

  22. ConversaJons  are  good.      We’re  more  likely  to  understand  what  customers  want  by  
    having  a  conversaJon  with  them  rather  than  reading  a  document.  
       
    During  conversaJons,  people  tell  stories.    Stories  give  us  even  be_er  insights  because  
    they  give  context  and  narraJve.    They  help  us  make  an  emoJonal  connecJon  and  
    care  about  what  we’re  doing.  
    22  

    View Slide

  23. Here’s  Jeff  Pa_on’s  definiJon  of  a  user  story.    Aaaah,  so  I  can  see  value  in  that.    
     
    23  

    View Slide

  24. I  went  to  a  workshop  last  year  run  by  Gemma  Cameron  on  Comic  Strip  User  Stories  
    led  by  Gemma  Cameron  –  has  anyone  heard  of  comic  user  stories?  
    24  

    View Slide

  25. They  all  end  with  someone  stood  with  their  arms  in  the  air  (put  arms  in  air)  and  a  
    yay!  Moment.    The  comic  strip  sets  the  context,  highlights  the  gap  or  the  current  pain  
    and  leads  to  an  awesome  outcome.  
       
     
    25  

    View Slide

  26. Here’s  mine  from.    Our  company  delivers  digital  retail  soluJons.  
       
    26  

    View Slide

  27. So  stories  are  supposed  to  help  you  understand  what  awesome  outcomes  really  look  
    like.      
       
    You’re  supposed  to  include  the  value  in  the  story  to  help  remind  you  of  why  you’re  
    doing  it.    That’s  why  you  have  the  so  that  /  in  order  to  bit  in  the  user  story  format.  
     
     
     
    27  

    View Slide

  28. But  you  ojen  see  stuff  like  this….  
     
    But  we’re  OK  in  the  BDD  world  because  we  put  the  value  first  to  make  sure  we’ve  got  
    it  
     
     
    28  

    View Slide

  29. Phew!  Thank  goodness  for  that  –  much  be_er.  
       
    The  value  part  shouldn’t  be  an  a?erthought  that  you  apply  in  order  to  follow  the  
    correct  user  story  convenJon,  it  should  be  much  more  proacAve  than  that.      
    29  

    View Slide

  30. They  all  end  with  someone  stood  with  their  arms  in  the  air  (put  arms  in  air)  and  a  
    yay!  Moment.    The  comic  strip  sets  the  context,  highlights  the  gap  or  the  current  pain  
    and  leads  to  an  awesome  outcome.  
       
     
    30  

    View Slide

  31. I  don’t  know  I’m  going  to  call  them  outcomes.    
    31  

    View Slide

  32. The  whole  point  of  iteraJve  delivery  is  to  allow  us  to  deliver  in  smaller  chunks  &  get  
    value  earlier  
     
    Not  this  
    32  

    View Slide

  33. Not  this.  
     
    You  can  sJll  get  analysis  paralysis  in  an  agile  project  
       
     
    33  

    View Slide

  34. So  we’ve  all  seen  this  before  
     
    IteraJve  versus  incremental  delivery.  
       
    The  scope  of  a  piece  of  work  is  the  same  regardless  of  how  you  deliver  it.    The  benefit  
    of  iteraJve  delivery  is  that  you  start  geVng  value  early  and  you  learn  quickly  and  can  
    change  direcJon  if  necessary.      This  normally  leads  to  less  work  because  it  becomes  
    apparent  more  quickly  that  a  lot  of  the  original  scope  isn’t  actually  needed.    You  
    might  be  able  to  stop  at  the  motorbike  and  sJll  get  the  outcomes  you  need.  
     
     
     
    34  

    View Slide

  35. The  most  important  concept  of  chunking  is  a  chunk  of  value  –  a  chunk  of  outcomes  
     
    You  need  to  a_ack  your  delivery  like  this  
       
    But  do  you  need  to  split  your  user  stories  to  this  Any  autonomous  unit  up  front  in  
    order  to  do  that?  
       
    No  –  first  you  need  to  explore  the  first  chunk  of  outcomes  and  how  we  deliver  value  
    in  the  leanest  possible  way.    
     
    But  where  do  you  start  with  that?  
     
    35  

    View Slide

  36. Has  anyone  heard  of  systems  theory?    Systems  theory  started  in  the  1940s  The  study  
    of  systems  in  general,  with  the  goal  of  discovering  pa_erns  that  can  be  applied  to  all  
    systems  in  physics,  biology  and  engineering.  
     
    System  Theory  says  this  
     
    The  value  of  a  system  or  process  lies  in  its  outputs.  
    We  know  it’s  good  to  focus  on  these.  
     
     
    36  

    View Slide

  37. 37  

    View Slide

  38. I  dunno,  I’m  going  to  call  them  outputs  
     
    To  find  out  how  are  systems  generate  valuable  outputs  we  need  to  think  of  how  the  
    thing  is  actually  going  to  work.    We  have  to  consider  the  user  interacJons  and  
    processes  that  are  required  to  make  sure  we  have  something  joined  up.  
     
    38  

    View Slide

  39. you  need  to  tell  a  story  about  the  interacAons  that  deliver  the  desired  outputs  and  
    outcomes.  
       
    You    need  to  think  about  acJviJes  and  events.  
       
     
    39  

    View Slide

  40. Here’s  a  quote  from  a  guy  called  Jeff  Pa_on  
       
    ‘Telling  the  Whole  Story’  
       
    In  2001  I  lej  the  team  I  was  on  and  started  doing  things  differently.    I,  and  my  team,  
    tried  an  approach  to  wriJng  stories  that  focused  on  the  big  picture.    We  worked  to  
    understand  the  product  we  were  building  and  to  make  trade-­‐offs  together.    We  used  
    that  bunch  of  index  cards  with  story  Jtles  to  organize  our  thoughts  and  break  down  
    that  big  picture  into  the  small  parts  we  could  build  next.    In  2004,  I  wrote  my  first  
    arJcular  about  this  idea.    I  didn’t  coin  the  term  story  mapping  unJl  2007  
       
    Then  he  started  running  into  people  who  were  doing  similar  things  –  he’d  discovered  
    a  pa_ern  
     
    40  

    View Slide

  41. Anyone  not  heard  of  story  mapping?    Anyone  want  to  describe  it?  
     
    So  in  story  mapping  you  tell  a  story  using  a  sequenJal  set  of  acJviJes  that  deliver  the  
    desired  outputs  and  outcomes.    The  map  is  a  narraJve  flow  across  many  users  and  
    systems.    Doing  this  helps  you  spot  holes  in  story  and  helps  you  consider  alternaJve  
    paths  and  opJons.  
       
    You’re  looking  for  the  minimum  viable  product.    ‘the  smallest  product  release  that  
    successfully  achieves  its  desired  outcomes’  
       
    And  the  really  cool  bit  of  story  mapping  is  where  you  find  the  ‘opening  game’  which  is  
    your  first  iteraJon  through  the  narraJve.    This  is  what  will  guide  you  strongly  in  your  
    development  iteraJon.    
     
    This  whole  thing  tells  a  story.  
     
    But  what  about  these  individual  lower  level  post  it  notes  here.    What  are  these?  
     
       
     
    41  

    View Slide

  42. I  dunno,  I’m  going  to  call  them  acJviJes.    As  part  of  a  process  
     
    So  we  don’t  need  to  track  user  stories  autonomously  down  to  the  lowest  level  to  be  
    successful  in  delivering  in  smaller  chunks  
    But  the  most  important  chunk  is  understanding  the  leanest  story  that  delivers  those  
    outcomes.  
     
    42  

    View Slide

  43. To  track  and  esAmate  work  
       
    This  bit  really  confuses  me.    
     
    You’ve  seen  already  how  user  stories  all  look  the  same  regardless  of  what  level  
    they’re  at  or  what  we’re  using  them  for.    Which  type  of  user  story  to  we  track  and  
    esJmate.      
     
    A  whole  outcome  user  story  unJl  it’s  done?  
    A  whole  output  user  story  unJl  it’s  done?  
    A  whole  acJvity  user  story  unJl  it’s  done?  
     
       
     
    43  

    View Slide

  44. You’ve  seen  the  problem  with  user  story  icebergs.    At  each  of  those  levels  of  detail,  
    there’s  always  more  under  the  surface.    An  a  lot  of  the  stuff  under  the  surface  might  
    not  be  that  important.    So  surely  we  don’t  want  to  track  the  actual  story  through  to  
    compleJon  at  any  of  those  levels,  because  we’re  going  to  iterate.  
     
     
    44  

    View Slide

  45. When  we’ve  got  concrete  examples  we  can  start  to  work  out  the  work  we  need  to  do  
    to  implement  them.      So  tracking  and  esJmaJng  work  at  the  example  level  makes  
    sense  to  me.  
    45  

    View Slide

  46. In  BDD  we  use  the  word  scenarios  a  lot  
    46  

    View Slide

  47. 47  

    View Slide

  48. I’m  pre_y  sure  they’re  tasks.    I’m  going  to  call  them  tasks.  
    48  

    View Slide

  49. OK  so  let’s  recap  with  the  User  Story  Starfish  
     
    Why  do  you  use  stories,  this  stuff  is  important,  you  want  to  have  conversaJons,  
    collaborate  and  chunk  things  down  so  that  you  can  deliver  value  as  early  as  possible.  
     
    To  stay  out  of  the  badlands  though,  you  need  to  be  aware  of  doing  too  much  up  front  
    analysis,    don’t  waste  Jme  adhering  to  silly  formats  if  they’re  not  necessary  and  
    recreaJng  user  story  format  Jckets  in  Jira  might  be  a  waste  of  Jme.    
     
    To  get  to  value  as  quickly  as  possible,  you  need  to  chunk  down  a  the  outcome  level,  
    and  be  aware  of  moving  through  different  levels  of  detail.    You  need  to  do  the  right  
    amount  of  documentaJon  to  join  up  with  your  BDD  pracJces,  use  the  right  tools  for  
    the  right  type  of  documenaJon.      You  should  do  less  unencessary  spliVng  of  user  
    stories  if  you  can  defer  diving  into  the  detail  unJl  later.      
     
    You  need  to  tell  the  whole  story.    By  capturing  the  processes  and  acJviJes  that  lead  
    to  the  valuable  outcomes.    And  track  work  at  the  example  level  rather  than  at  the  
    user  story  level.  
     
    49  

    View Slide

  50. OOPSI  
    So  how  do  you  do  that.    How  do  you  support  the  intended  use  of  stories  whilst  
    staying  out  of  the  badlands  
     
    I’d  like  to  introduce  the  OOPSI  model  for  agile  analysis.    OOPSI  stands  for  Outcome,  
    Output,  Process,  Scenarios,  Inputs.      
     
    The  OOPSI  technique  accelerates  delivery  by  helping  you  structure  your  discovery  
    acAviAes  so  that  you  are  always  working  on  the  right  thing  and  can  see  the  bigger  
    picture.    It  will  give  you  a  narraAve  and  context  for  your  analysis  artefacts  and  the  
    examples,  tests,  and  scenarios  that  support  them.  
       
    It’s  an  extended  version  of  Chris  Ma_’s  feature  injecJon  OOPI,  but  includes  scenarios  
    to  help  bring  together  BDD  and  specificaJon  by  example  techniques  
     
     
     
    50  

    View Slide

  51. So  here’s  how  OOPSI  Mapping  works.    A  bit  like  Ma_  Wynnes  example  mapping,  but  
    a  bit  more  structured  
     
    So  starJng  with  Outcomes  
     
    This  could  be  a  typical  outcome  user  story,    or  a  comic  strip  user  story  Gemma  
    Cameron  style.  
     
    Or  you  might  not  even  need  a  user  story.    If  you’ve  explored  goals  and  outcomes  by  
    doing  impact  mapping,  you’ll  already  have  the  goal,  outcome  and  actor.  
     
    Then  we  look  at  Outputs  
     
    This  is  a  really  important  step.    You  know  that  the  valuable  parts  of  your  systems  are  
    in  the  outputs.      You  want  to  illustrate  these  using  examples.    Draw  them.    Do  this  
    exploraJon  collaboraJvely  with  the  domain  expert.    This  part,  exploring  outputs  
    works  really  nicely  with  DDD.    As  you  explore  the  outputs  the  understanding  of  the  
    domain  rises  and  you  start  to  design  your  first  iteraJon  of  your  data  model.  
     
    So  now  we’re  onto  the  Process  part.  
     
    51  

    View Slide

  52. This  is  definitely  a  collaboraJve  discussion  with  the  key  domain  experts  and  
    stakeholders.    By  choosing  a  small  set  of  important  outputs  and  illustraJng  them  you  
    get  a  really  good  idea,  quickly  of  what  value  looks  like  from  the  customer.    You  
    already  have  some  concrete  examples.    You  know  that  if  you  could  demonstrate  
    these  outputs  being  produced,  the  customer  will  thing  that’s  awesome.  
     
    Also  we  start  to  get  a  good  idea  of  the  type  of  data  and  interfaces  that  your  system  
    needs  to  support.    But  you  don’t  need  to  get  becalmed  by  analysis  paralysis  because  
    you’re  going  to  choose  the  most  useful  output  to  start  with.  
     
    Which  output  is  the  most  fundamental  and  important  to  the  customer?  
    52  

    View Slide

  53. So  let’s  take  the  most  simple  type  of  coupon.  
     
    Based  on  products  in  the  basket.    What  process  will  generate  these  outputs?  
     
    What  are  the  main  scenarios?  
    53  

    View Slide

  54. Our  BDD  scenarios,  if  we  don’t  use  SBE  technique  ojen  don’t  go  down  to  this  level  of  
    detail.    I  think  this  is  where  all  the  magic  happens  and  we  get  to  start  to  properly  
    understand  the  domain.    We  need  to  properly  think  about  this  stuff  before  we  build  
    our  APIs.    I  think  some  key  examples  like  this  on  our  wiki  are  really  useful  
    54  

    View Slide

  55. So  you  may  have  noJced  these  detailed  examples  tend  to  resolve  around  one  of  the  
    acJvity  boxes.    In  this  case  ‘evaluate  promoJons’    in  our  first  iteraJon,  we’re  not  too  
    worried  about  potenJal  prinJng  problems,  The  scanning  of  items  at  the  Jll  is  exisJng  
    retailer  funcJonality,  so  we’re  really  focusing  on  the  evaluaJon  bit..  
     
    Let’s  look  at  another.    
    55  

    View Slide

  56. Does  that  affect  the  process?    Yes  –  we  need  to  scan  a  loyalty  card  for  this  type  of  
    scenario  
    56  

    View Slide

  57. That  has  introduced  some  addiJonal  a_ributes  and  broken  the  model  from  the  
    previous  example.    So  we  might  extend  our  soluJon  to  support  this  for  our  second  
    iteraJon.  
    57  

    View Slide

  58. And  we’d  have  other  tests  focusing  on  the  recognising  and  validaJng  the  loyalty  card.    
    They  don’t  sit  with  the  evaluate  promoJons  test,  they’ll  sit  around  the  ‘scan  loyalty  
    card’    acJvity  box.  
    If  we  wanted  to,  we  could  organise  our  documentaJon  on  a  wiki  hanging  off  these  
    boxes.    That’s  not  complete  madness.    It’s  how  use  cases  used  to  work  and  be  
    organised.  
     
    Whether  you  start  in  gherkin  or  with  tables  the  most  raJonalised  expression  of  the  
    test  tends  to  bring  it  down  to  this  level.    You  only  want  to  evaluate  one  thing  in  each  
    test  
     
     
    58  

    View Slide

  59. And  then  as  we  get  more  sophisJcated  we  deal  with  new  capabiliJes  all  together.    
    Some  of  this  we  can  short  cut  and  some  of  it  will  extend  our  soluJon.      We  might  
    need  to  refactor.  
     
    You  can  see  how  more  key  examples  would  develop  around  the  push  coupon  to  
    mobile  app  acJvity  box.  
     
    All  of  these  examples  and  tests  we  have  talked  about  so  far  guide  development  really  
    strongly.    We  can  build  them  one  at  a  Jme  and  build  unit  tests  TDD  style  and  have  
    high  confidence  that  our  system  is  going  to  work  as  expected.      We  might  build  up  
    some  regression  tests  around  our  APIs  to  support  the  key  evaluaJon  funcJonality.    
    Using  OOPSI  helps  us  recognise  when  we’re  working  at  different  levels  of  detail.    Take  
    a  look  at  this.  
    59  

    View Slide

  60. Once  we’ve  delivered  all  this  capability  and  we’re  running  in  producJon  –  we  might  
    have  some  automated  higher  level  tests  that  ensure  we  generate  all  the  different  
    outputs.    These  tests  might  check  the  actual  output  more  carefully  to  make  sure  all  
    the  steps  in  the  process  are  working,  including  the  reporJng.  
     
     
    60  

    View Slide

  61. That  was  OOPSI  
    It  helps  you  chunk  down  and  start  small  –  so  you’re  not  overwhelmed  with  detail  
    It  helps  you  see  the  big  picture  and  recognise  where  you  are  in  the  discovery  process  
    –  so  that  you  don’t  get  lost  
    It  helps  you  only  examine  the  most  important  Jp  of  the  iceberg  and  generate  the  
    right  amount  appropriate  documentaJon  –  so  that  your  projects  don’t  get  sunk  
     
    61  

    View Slide

  62. It  helps  us  with  navigaJon  and  design  thinking.    At  each  progression  we  evaluate  
    opJons  and  make  decisions  to  choose  the  most  important  ones.  You  may  have  
    noJced  that  if  you  a_ack  this  the  other  way  round  it  ISPOO.  
     
    62  

    View Slide

  63. So  hopefully  I’ve  convinced  you  that  there  is  a  way  to  avoid  death  by  user  stories  
    There’s  even  a  way  to  avoid  user  stories  altogether  
    By  using  this  OOPSI  approach  –  Outcomes,  Outputs,  Process,  Scenarios,  Inputs  you  
    stay  out  of  the  badlands  
     
     
    63  

    View Slide

  64. Stay  on  the  safe  path  to  value,  and  achieve  awesome  outcomes  
     
    64  

    View Slide

  65. 65  

    View Slide