Introduction to Agile Project Management and Scrum


Published on

Brief introduction to Agile Project Management and Scrum covering user stories, story points, use of Fibonacci sequence values for story points, release planning, sprints, capacity, velocity, sprint commit meetings, sprint review meetings, and burndown charts. Explains the importance of returning the product to a potentially shippable state at the end of each sprint to reduce the accumulation of technical debt and keep the assessment of project progress realistic. Summarizes the roles in Scrum of the Product Owner (who writes or facilitates the writing by customers of user stories), the ScrumMaster (who manages the Scrum), and the Team (who do the work). Discusses values and best practices in Agile/Extreme Programming ("XP") values. Explains daily standup meeting in which people share what they did yesterday, what they’re doing today, and any blocking issues they’re encountering. Summarizes common problems with waterfall project management including a serialized process, longer time to market, isolation of developers from customer needs, plans falling out of synch with reality, lack of visibility into rate of progress, features being slashed late in the development cycle to bring in release dates, long time to project completion, late feedback from customers, projects falling behind schedule, and projects missing their market window or being killed before launch. Summaries problems with monolithic product requirements documents including length, lack of readability, disconnection from customer needs, and lack of clarity about which features are for which customers.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction to Agile Project Management and Scrum

  1. 1. Eric  Krock   Co-­‐Founder,  Voximate!/voximate  
  2. 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. 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. 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. 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. 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. 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. 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. 9. Development  Concepts    Test  driven  design*    Depth-­‐first  development  * Source: Kent Beck, XP Explained
  10. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. Addi7onal  Resources     Mike  Cohn’s  site  with  blog,  presentations,  more      