Introduction to Agile Project Management and Scrum

Introduction to Agile Project Management and Scrum

• 1.
  Eric  Krock   Co-­‐Founder,  Voximate   http://twitter.com/#!/voximate   http://www.voximate.com/blog/  
• 2.
  Why  Waterfall  Usually  Sucks   Problem   Consequences   Serialized  process:  MRD   Longer  time  to  market;  developers  isolated  from   –  PRD  –  Design   customer  needs   Document  –  Dev  -­‐  QA   Planning  far  in  advance   Plans  no  longer  match  reality  by  the  time  they’re   implemented   Lack  of  visibility  into   Teams  don’t  realize  they’re  behind  schedule  until  too   rate  of  progress   late   Features  slashed  very  late  to  compensate,  wasting   effort  and  leading  to  Swiss-­‐cheese  products  (e.g.  MS   Kin)   Long  time  to  project   Customers  get  access  to  new  features  infrequently   completion   and  after  long  delay   Customers  can  only  provide  feedback  “too  late”   Process  doesn’t  allow  for  rapid  incremental  learning   Projects  fall  behind   Projects  miss  market  window  or  are  killed  before   schedule   launch  
• 3.
  Why  PRDs  Usually  Suck     Long     Monolithic     Unreadable  and  unread     Often  disconnected  from  actual  customer  needs     Lack  of  clarity  about  what  features  are  for  which   customers  
• 4.
  User  Stories    Express  a  customer  need  as  a  story  about  a  real  or   composite  user  in  the  language  of  the  customer     As  a  [USER  ROLE],  I  [must  /  want  /  wish  to]  [need]  so   that  [user  goal]     Short:  can  fit  on  an  index  card     Example:  “As  a  project  manager,  I  must  track  each   task’s  delivery  deadline  so  that  I  can  make  sure  tasks   are  completed  on  team.”     Small  amount  of  work:  can  fit  within  a  day  or  a  sprint     Should  include  notes  for  needed  acceptance  test   Source: Mike Cohn, User Stories Applied
• 5.
  Es7mate  Effort  for  Story  in  Points     “Story  point”  =  abstract,  RELATIVE  estimate  of   amount  of  work  to  complete  a  story     Optional:  Using  Fibbonacci  sequence  forces  clear   distinctions  in  difficulty:  1,  2,  3,  5,  8,  13,  21  …     Teams  must  agree  on  estimate  for  each  story     Tracking  velocity  (points  completed  per  sprint)  will   measure  team’s  true  capacity     Issues:  measure  with  points,  or  not?   Source: Mike Cohn, Agile Estimating and Planning
• 6.
  Release  Plan    Combines  multiple  sprints  to  achieve  larger  goal     Capacity  =  number  of  sprints  *  expected  velocity     Choose  list  of  stories  with  total  story  points  no  greater   than  capacity   Source: Mike Cohn, Agile Estimating and Planning, Chapter 13, “Release Planning”
• 7.
  Divide  Workload  Into  Short  Sprints     Sprint  =  short,  fixed-­‐length  interval  for  development     Usually  1-­‐2  weeks     Key:  Must  return  product  to  potentially  shippable   state  at  end  of  sprint!     Reduces  accumulation  of  technical  debt     Keeps  assessment  of  project  progress  realistic  
• 8.
  Key  Concepts  in  Scrum     Product  Owner:  voice  of  the  customer,  facilitates   writing  of  user  stories     ScrumMaster:  manages  the  sprints     Team:  do  the  work!     Collective  ownership     Daily  standup:  did  yesterday,  doing  today,  stuck  on  …   Source: Mike Cohn, User Stories Applied, Chapter 15
• 9.
  Development  Concepts    Test  driven  design*     Depth-­‐first  development   * Source: Kent Beck, XP Explained
• 10.
  Sprint  Commit  Mee7ng     At  start  of  each  sprint,  team  meets  and  commits   which  stories  they  will  do  for  the  sprint.     Make  decision  based  on  tasks  for  each  story  and   estimated  hours  for  all  tasks,  not  based  on  points.     Key:  After  sprint  commit  meeting,  no  new  stories  can   be  added  to  that  sprint.       For  true  emergencies,  must  remove  equal  amount  of   work  if  add  something  in  after  sprint  commit.   Source: Mike Cohn, User Stories Applied
• 11.
  User  Stories    Conversa7ons     User  story  is  basis  for  a  conversation  with  developer     Conversation  (not  the  user  story)  is  basis  for  actual   development     Goals:     Get  engineering  talking  to  product  owner,  customers,   etc.     Get  deeper  mutual  understanding  of  the  story  by   talking  about  it     Increase  odds  that  features  developed  will  actually   satisfy  customer’s  needs   Source: Mike Cohn, User Stories Applied
• 12.
  Sprint  Burndown  Chart   Sprint  Hours  of  Work  Remaining   70   60   50   40   30   20   10   0   3/27/11   3/28/11   3/29/11   3/30/11   3/31/11   4/1/11  
• 13.
  Sprint  Review  Mee7ng     At  end  of  sprint,  review  what  work  actually  got  done.     Velocity  =  total  points  for  all  user  stories  completed   during  sprint.     No  partial  credit  for  partially-­‐complete  stories!     Estimated  time  to  project  completion  =     total  story  points  for  all  stories  in  project  /     moving  average  of  velocity     Moving  average  =  average  velocity  of  last  three  sprints     Team’s  accuracy  estimating  doable  work  per  sprint   should  improve  over  time   Source: Mike Cohn, Agile Estimating and Planning
• 14.
  Project  Burndown  Chart   400   350   300   250   Points  Closed   200   Points  Added   150   Points  Remaining   100   50   0   1/7/11   1/14/11   1/21/11   1/28/11   2/4/11   2/11/11   2/18/11   2/25/11   3/4/11  
• 15.
  Backlog:  Per-­‐Project,  or  Per-­‐Release?     Backlog  is  list  of  all  stories  not  yet  assigned  to  a  sprint     Simple  project,  single  release:  single  backlog     Benefit:  simplicity     Long-­‐lived  project  with  multiple  releases:  may  have   one  backlog  per  release     Benefit:  do  initial  division  of  work  by  release,  then   divide  each  release’s  work  into  sprints  during   development;  product  owner  needn’t  review  ALL  stories   at  every  sprint  
• 16.
  Agile  Best  Prac7ces   Best  Practice   Benefit   Don’t  write  stories  too  far  in  advance  of   Avoid  wasted  effort  on  stories  that  are   development.*   not  implemented.   Use  best,  most-­‐current  information   when  writing  story.   Don’t  event  tentatively  schedule  stories   Avoid  wasted  effort  of  moving  stories   more  than  2-­‐3  sprints  in  advance.   when  priorities  change.   Have  customers  write  and  prioritize   Let  customers  express  their  needs.   user  stories.*   Avoid  “telephone  game”  problem.   Force  customers  to  make  tradeoffs.   * Source: Mike Cohn, User Stories Applied
• 17.
  Key  Agile  Values     Communication     Transparency     Honesty     Incremental  effort     Incremental  learning  feedback   For fuller list of Agile / XP values, see Kent Beck, XP Explained, Chapters 3-5
• 18.
  Agile  Versus  Tradi7onal  Waterfall   Metric   Waterfall   Agile   Planning  scale   Long-­‐term   Short-­‐term   Distance  between   Long   Short   customer  and  developer   Time  between   Long   Short   specification  and   implementation   Time  to  discover   Long   Short   problems   Project  schedule  risk   High   Low   Ability  to  respond   Low   High   quickly  to  change  
• 19.
  Addi7onal  Reading   Book   Author   Notes   User  Stories  Applied   Mike  Cohn   Intro  to  Agile  and  use  of  user  stories   for  expressing  requirements.   Agile  Estimating  and   Mike  Cohn   Deep  dive  on  Agile  metrics,   Planning   estimating,  and  project  planning.   Succeeding  with  Agile   Mike  Cohn   Tips  on  rolling  out  Agile  in  a  larger   organization.   Extreme  Programming   Kent  Beck  &   Introduction  to  XP   Explained   Cynthia   Andres  
• 20.
  Addi7onal  Resources    http://www.mountaingoatsoftware.com/   Mike  Cohn’s  site  with  blog,  presentations,  more     http://agilemanifesto.org/     http://www.agilealliance.org/     http://www.scrumalliance.org/