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

Death by User Stories

9fca21e96d2e4d947cf8ac528ba057da?s=47 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


  1. Hi,  I’m  Jenny  –  I’ve  been  doing  a  lot  of

     thinking  recently  about  user  stories  and  I’ve   been  wondering….     1  
  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  
  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  
  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  
  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  
  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  
  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  
  8. Maybe  it’s  the  acceptance  criteria  that  are  supposed  to  do

     that?       8  
  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  
  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  
  11. This  is  how  we  have  been  made  to  feel  about

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

     Smiling!   12  
  13. DocumentaJon  –  booooo,  waste  of  Jme     13  

  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  
  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  
  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  
  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  
  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  
  19. 19  

  20. 20  

  21. 21  

  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  
  23. Here’s  Jeff  Pa_on’s  definiJon  of  a  user  story.    Aaaah,

     so  I  can  see  value  in  that.       23  
  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  
  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  
  26. Here’s  mine  from.    Our  company  delivers  digital  retail  soluJons.

  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  
  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  
  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  
  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  
  31. I  don’t  know  I’m  going  to  call  them  outcomes.  

  32. The  whole  point  of  iteraJve  delivery  is  to  allow  us

     to  deliver  in  smaller  chunks  &  get   value  earlier     Not  this   32  
  33. Not  this.     You  can  sJll  get  analysis  paralysis

     in  an  agile  project         33  
  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  
  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  
  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  
  37. 37  

  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  
  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  
  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  
  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  
  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  
  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  
  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  
  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  
  46. In  BDD  we  use  the  word  scenarios  a  lot  

  47. 47  

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

     them  tasks.   48  
  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  
  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  
  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  
  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  
  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  
  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  
  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  
  56. Does  that  affect  the  process?    Yes  –  we  need

     to  scan  a  loyalty  card  for  this  type  of   scenario   56  
  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  
  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  
  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  
  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  
  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  
  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  
  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  
  64. Stay  on  the  safe  path  to  value,  and  achieve  awesome

     outcomes     64  
  65. 65