Your SlideShare is downloading. ×
0
User	
  
Stories	
  
Tathagat	
  Varma	
  
h0p://managewell.net	
  	
  
h0p://leanso8wareengineering.com/2007/11/14/planning-­‐a-­‐month-­‐or-­‐less-­‐ahead-­‐is-­‐not-­‐enough/	
  	
  
Agile	
  Planning	
  Onion	
  
Strategy	
  
PorFolio	
  
Product	
  
Release	
  
IteraIon	
  
Daily	
  
Product	
  Management	
  ArIfacts	
  
IniIaIves	
  	
  
Epics	
  
Themes	
  
Sprint	
  Backlog	
  
Product	
  Backlog	
  
...
Product	
  Vision	
  
•  Shared	
  by	
  All	
  
•  Desirable	
  and	
  InspiraIonal	
  
•  Clear	
  and	
  Tangible	
  
•...
Product	
  Vision	
  –	
  Elevator	
  Pitch	
  
For	
  (target	
  customer)	
  
Who	
  (statement	
  of	
  the	
  need	
  ...
Product	
  Vision	
  Box	
  
•  As	
  the	
  name	
  
suggests…	
  
•  Describes	
  the	
  top	
  
2-­‐3	
  features	
  of...
Product	
  Roadmap	
  
h0p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/	
  ...
Product	
  Backlog	
  
•  A	
  combined	
  list	
  of	
  all	
  desired	
  work,	
  including	
  
user	
  focused	
  stori...
Benefits	
  of	
  Product	
  Roadmap	
  
•  Helps	
  communicate	
  how	
  you	
  see	
  the	
  product	
  develop.	
  
•  ...
Product	
  Backlog	
  
•  The	
  agile	
  product	
  backlog	
  is	
  a	
  prioriIzed	
  
features	
  list,	
  containing	...
Who	
  owns	
  Product	
  Backlog?	
  
h0p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐produc...
….should	
  be	
  “DEEP”	
  
•  Emergent	
  •  PrioriIzed	
  
•  EsImated	
  •  Detailed	
  
Appropriately	
  
D	
   E	
  ...
From	
  Product	
  Roadmap	
  to	
  Product	
  
Backlog	
  
h0p://www.romanpichler.com/blog/agile-­‐product-­‐management-­...
Sprint	
  Backlog	
  
•  User	
  Stories	
  selected	
  
by	
  The	
  Team	
  
•  Will	
  be	
  built	
  in	
  next	
  
Sp...
Sprint	
  Backlog	
  
User	
  Story	
  
I as a <Role>
	
  
want <Feature>
	
  
so that <Value>
Why	
  User	
  Stories?	
  
h0p://www.agilebuddha.com/wp-­‐content/uploads/2012/05/User-­‐Stories.jpg	
  	
  
Why	
  not	
  ‘PRDs’?	
  
User	
  Story	
  
h0p://www.leadingagile.com/wp-­‐content/uploads/2012/07/post-­‐it-­‐note-­‐user-­‐story.jpg	
  	
  
h0ps...
As	
  a	
  frequent	
  flyer,	
  
	
  
I	
  want	
  to	
  be	
  able	
  to	
  view	
  current	
  
offers	
  in	
  terms	
  o...
Acceptance	
  Criteria	
  
22	
  
Given <System State>

when <an event occurs>

then <an outcome happens>
The	
  Three	
  C’s	
  of	
  a	
  User	
  Story	
  
• The	
  story	
  itself	
  
• A	
  promise	
  to	
  have	
  a	
  conv...
What	
  makes	
  a	
  good	
  User	
  Story?	
  
Independent	
  of	
  all	
  others	
  
NegoIable	
  not	
  a	
  specific	
...
Scenarios,	
  User	
  Case,	
  User	
  Story	
  
Use	
  Case:	
  
	
  
Customer	
  walks	
  to	
  the	
  restaurant	
  
Cu...
Themes,	
  Epics,	
  Stories,	
  Tasks	
  
Themes	
  
•  We	
  could	
  put	
  a	
  rubber	
  band	
  around	
  that	
  
group	
  of	
  stories	
  I	
  wrote	
  abou...
Themes	
  change/evolve…	
  
Scrum	
  Product	
  Ownership	
  –	
  Bob	
  Galen	
  
Epics	
  
•  A	
  Scrum	
  epic	
  is	
  a	
  large	
  user	
  story.	
  There's	
  no	
  magic	
  threshold	
  at	
  
whi...
User	
  Stories	
  
•  A	
  user	
  story	
  is	
  simply	
  something	
  a	
  user	
  wants.	
  
User	
  stories	
  are	
...
Epics	
  -­‐>	
  Stories	
  
Performance	
  Constraint	
  -­‐>	
  Acceptance	
  
Criteria	
  
Minimal	
  Marketable	
  Feature	
  
•  A	
  Minimal	
  Marketable	
  Feature	
  (MMF)	
  is	
  a	
  feature	
  that	
  is...
MVP,	
  MMF,	
  Stories	
  
MVP	
  
MMFs	
  
User	
  Stories	
  
MoSCoW	
  
•  M	
  -­‐	
  MUST:	
  Describes	
  a	
  requirement	
  that	
  must	
  be	
  saIsfied	
  in	
  
the	
  final	
 ...
Spliung	
  User	
  Stories	
  
h0p://gojko.net/2012/01/23/spliung-­‐user-­‐stories-­‐the-­‐hamburger-­‐method/	
  	
  
1.	
  IdenIfy	
  Tasks	
  
2.	
  IdenIfy	
  opIons	
  for	
  tasks	
  
3.	
  Combine	
  Results	
  
4.	
  Trim	
  the	
  Hamburger	
  
5.	
  Take	
  the	
  first	
  bite!	
  
6.	
  Take	
  another	
  bite…and	
  conInue	
  
User	
  Story	
  Mapping	
  
45	
  
©	
  Jeff	
  Pa0on,	
  all	
  rights	
  reserved,	
  www.AgileProductDesign.com	
  
The	
  user	
  story	
  map	
  c...
48	
  
©	
  Jeff	
  Pa0on,	
  all	
  rights	
  reserved,	
  www.AgileProductDesign.com	
  
Planning	
  incremental	
  relea...
Scenarios	
  
•  A	
  usage	
  scenario,	
  or	
  scenario	
  for	
  short,	
  describes	
  
a	
  real-­‐world	
  example	...
Learning	
  and	
  Emergence	
  
EsImaIon	
  
h0p://www.agilenutshell.com/episodes/3-­‐esImaIon	
  	
  
Use	
  any	
  measure…consistently	
  
Story	
  Points	
  
•  Agile	
  teams	
  generally	
  prefer	
  to	
  express	
  esImates	
  in	
  units	
  other	
  
than...
EsImaIon	
  
Mainly	
  two	
  forms	
  of	
  esImaIon	
  	
  
–  Analogous	
  EsImaIon	
  [T-­‐Shirt	
  Sizing	
  -­‐	
  S...
Affinity	
  EsImaIng	
  Guidelines	
  
Break	
  up	
  into	
  small	
  teams	
  of	
  2-­‐4	
  
Discuss	
  2-­‐3	
  stories	...
Affinity	
  EsImaIng	
  
56	
  
References	
  
•  h0p://www.scrumcrazy.com/A+User+Story+Checklist	
  
•  h0p://www.scrumcrazy.com/User+Story+Basics+-­‐+Th...
User Stories
User Stories
User Stories
User Stories
Upcoming SlideShare
Loading in...5
×

User Stories

956

Published on

A training session I did on User Stories.

Published in: Software, Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
956
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
62
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "User Stories"

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

    Clipping is a handy way to collect important slides you want to go back to later.

×