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  Vision  

Product  Roadmap  

Product  Backlog  

Sprint  Backlog  

Themes  

IniIaIves    

Epics  

Scenarios  

Stories  
Product  Management  ArIfacts  

Tasks…  
 Product  Vision  
•  Shared  by  All  
•  Desirable  and  InspiraIonal  
•  Clear  and  Tangible  
•  Broad  and  Engaging  
•  Short  and  Sweet  
 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    
Product  Vision  Box  

•  As  the  name  
suggests…  
•  Describes  the  top  
2-­‐3  features  of  
product  
 Product  Roadmap  
•  High-­‐level  plan  that  
describes  how  the  
h0p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
product  will  evolve  

•  Refers  to  
•  Product  version  
•  FuncIonality  
•  Release  date    

h0p://dynamicsgpblogster.files.wordpress.com/2009/04/dynamicsgproadmap4.png    
 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  
 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/    
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    
 Who  owns  Product  Backlog?  

h0p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
 ….should  be  “DEEP”  
•  Detailed   •  EsImated  
Appropriately  

D   E  

P   E  
•  PrioriIzed   •  Emergent  
 From  Product  Roadmap  to  Product  
Backlog  

h0p://www.romanpichler.com/blog/agile-­‐product-­‐management-­‐tools/agile-­‐product-­‐roadmap/    
 Sprint  Backlog  
•  User  Stories  selected  
by  The  Team  
•  Will  be  built  in  next  
Sprint  
•  Fully  EsImated  
•  Divided  into  Tasks  
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://code.google.com/p/econference-­‐planning-­‐poker-­‐plugin/wiki/PlanningPoker    
As  a  frequent  flyer,  
 
I  want  to  be  able  to  view  current  
offers  in  terms  of  mileage  points  
 
so  that  I  can  redeem  them.  
 Acceptance  Criteria  

Given <System State>

when <an event occurs>

then <an outcome happens>

22  
 The  Three  C’s  of  a  User  Story  
• The  story  itself  
Card   • A  promise  to  have  a  conversaIon  at  the  
appropriate  Ime  

• The  requirements  themselves  communicated  

from  the  Product  Owner  to  the  Delivery  Team  via  
ConversaIon   a  conversaIon  
• Write  down  what  is  agreed  upon  

• The  Acceptance  Criteria  for  the  story  

ConfirmaIon   • How  the  Delivery  Team  will  know  they  have  
completed  the  story  
 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    
 Scenarios,  User  Case,  User  Story  
Scenario:   Use  Case:  
   
Josh  is  a  30  something  mid-­‐level  manager   Customer  walks  to  the  restaurant  
for  an  ad  agency,  metro-­‐sexual  and  beer   Customer  enters  the  restaurant  
aficionado.  He  likes  to  try  new  and  exoIc   Customer  finds  a  seat  at  the  bar  
beers  in  trendy  locaIons.  He  also  enjoys   Customer  scans  the  menu  
using  a  variety  of  social  apps  on  his  smart   Customer  selects  a  beer  
phone.  He  reads  a  review    on  Yelp  of  a  new   Customer  orders  selected  beer  
burger  &  beer  joint  downtown  with  over   Bartender  takes  order  
100  beers  on  tap,  and  decides  to  go  walk   Bartender  pours  beer  
over  a8er  work  and  check  it  out.   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/    
Themes,  Epics,  Stories,  Tasks  
 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    
 Themes  change/evolve…  

Scrum  Product  Ownership  –  Bob  Galen  

 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    
 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    
Epics  -­‐>  Stories  
Performance  Constraint  -­‐>  Acceptance  
Criteria  
 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.  
 
 MVP,  MMF,  Stories  

MVP  

MMFs  
User  Stories  
 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.  
 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  
 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  

The backbone
time

The walking skeleton

necessity  

45  
©  Jeff  Pa0on,  all  rights  reserved,  www.AgileProductDesign.com  
 Planning  incremental  releases  can  be  
facilitated  as  a  collaboraIve  event  

48  
©  Jeff  Pa0on,  all  rights  reserved,  www.AgileProductDesign.com  
 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.        
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  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    
 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.  
 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  

Affinity  EsImaIng  

56  
 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