Eric	  Krock	  Principal	  Consultant	  and	  Trainer,	  280	  Group	       ©	  2011-­‐2012	  Eric	  Krock	  Marketing	  S...
Why	  Waterfall	  Usually	  Sucks	  Problem	                                      Consequences	  Serialized	  process:	  M...
Why	  PRDs	  Usually	  Suck	    Long	    Monolithic	    Unreadable	  and	  unread	    Often	  disconnected	  from	  ac...
User	  Stories	    Express	  a	  customer	  need	  as	  a	  story	  about	  a	  real	  or	     composite	  user	  in	  th...
Es7mate	  Effort	  for	  Story	  in	  Points	    “Story	  point”	  =	  abstract,	  RELATIVE	  estimate	  of	     amount	  ...
Release	  Plan	    Combines	  multiple	  sprints	  to	  achieve	  larger	  goal	    Capacity	  =	  number	  of	  sprints...
Divide	  Workload	  Into	  Short	  Sprints	    Sprint	  =	  short,	  fixed-­‐length	  interval	  for	  development	    Us...
Key	  Concepts	  in	  Scrum	    Product	  Owner:	  voice	  of	  the	  customer,	  facilitates	     writing	  of	  user	  ...
Development	  Concepts	    Test	  driven	  design*	    Depth-­‐first	  development	  * Source: Kent Beck, XP Explained   ...
Sprint	  Commit	  Mee7ng	    At	  start	  of	  each	  sprint,	  team	  meets	  and	  commits	     which	  stories	  they	...
User	  Stories	  	  Conversa7ons	    User	  story	  is	  basis	  for	  a	  conversation	  with	  developer	    Conversa...
Sprint	  Burndown	  Chart	                                Sprint	  Hours	  of	  Work	  Remaining	        70	        60	   ...
Sprint	  Review	  Mee7ng	    At	  end	  of	  sprint,	  review	  what	  work	  actually	  got	  done.	    Velocity	  =	  ...
Project	  Burndown	  Chart	  400	  350	  300	  250	                                                                       ...
Backlog:	  Per-­‐Project,	  or	  Per-­‐Release?	    Backlog	  is	  list	  of	  all	  stories	  not	  yet	  assigned	  to	...
Agile	  Best	  Prac7ces	  Best	  Practice	                                                               Benefit	  Don’t	  ...
Key	  Agile	  Values	    Communication	    Transparency	    Honesty	    Incremental	  effort	    Incremental	  learnin...
Agile	  Versus	  Tradi7onal	  Waterfall	  Metric	                                         Waterfall	                      ...
Addi7onal	  Reading	  Book	                                   Author	                          Notes	  User	  Stories	  Ap...
Addi7onal	  Resources	  	     Mike	  Cohn’s	  site	  with	  blog,	  presentations,	...
Stay	  in	  Touch!	  	  	    My	  email	  list:	  ...
Upcoming SlideShare
Loading in...5

Agile Project Management and Scrum Introduction


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, Business
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Transcript of "Agile Project Management and Scrum Introduction"

  1. 1. Eric  Krock  Principal  Consultant  and  Trainer,  280  Group   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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” ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  9. 9. Development  Concepts    Test  driven  design*    Depth-­‐first  development  * Source: Kent Beck, XP Explained ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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  even  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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 ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  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   ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  20. 20. Addi7onal  Resources     Mike  Cohn’s  site  with  blog,  presentations,  more         ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  21. 21. Stay  in  Touch!        My  email  list:­‐f     ©  2011-­‐2012  Eric  Krock  Marketing  Services  Inc.  All  rights  reserved.    
  1. A particular slide catching your eye?

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