Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

of

Introduction to Agile Project Management and Scrum Slide 1 Introduction to Agile Project Management and Scrum Slide 2 Introduction to Agile Project Management and Scrum Slide 3 Introduction to Agile Project Management and Scrum Slide 4 Introduction to Agile Project Management and Scrum Slide 5 Introduction to Agile Project Management and Scrum Slide 6 Introduction to Agile Project Management and Scrum Slide 7 Introduction to Agile Project Management and Scrum Slide 8 Introduction to Agile Project Management and Scrum Slide 9 Introduction to Agile Project Management and Scrum Slide 10 Introduction to Agile Project Management and Scrum Slide 11 Introduction to Agile Project Management and Scrum Slide 12 Introduction to Agile Project Management and Scrum Slide 13 Introduction to Agile Project Management and Scrum Slide 14 Introduction to Agile Project Management and Scrum Slide 15 Introduction to Agile Project Management and Scrum Slide 16 Introduction to Agile Project Management and Scrum Slide 17 Introduction to Agile Project Management and Scrum Slide 18 Introduction to Agile Project Management and Scrum Slide 19 Introduction to Agile Project Management and Scrum Slide 20
Upcoming SlideShare
Agile Project Management
Next
Download to read offline and view in fullscreen.

18 Likes

Share

Download to read offline

Introduction to Agile Project Management and Scrum

Download to read offline

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.

Related Books

Free with a 30 day trial from Scribd

See all

Introduction to Agile Project Management and Scrum

  1. 1. Eric  Krock   Co-­‐Founder,  Voximate   http://twitter.com/#!/voximate   http://www.voximate.com/blog/  
  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     http://www.mountaingoatsoftware.com/   Mike  Cohn’s  site  with  blog,  presentations,  more     http://agilemanifesto.org/     http://www.agilealliance.org/     http://www.scrumalliance.org/  
  • SleymanAkay1

    Oct. 8, 2017
  • NirmalMaurya1

    Sep. 26, 2017
  • AdrianMentelski

    Aug. 28, 2017
  • SladjanaSoskic

    Feb. 23, 2017
  • SnPhm

    Feb. 13, 2017
  • tarekkaddoumi

    Nov. 30, 2016
  • jonbusby1

    May. 30, 2016
  • alexermolin5

    Dec. 1, 2015
  • masteramuk

    Dec. 1, 2015
  • XIEWEIXIANG

    Oct. 6, 2015
  • KVIshwa

    May. 30, 2015
  • TraceyMarshall3

    May. 27, 2015
  • BrAndrsn

    Sep. 18, 2013
  • OpSoBoCa

    Sep. 18, 2013
  • massimilianozani

    Dec. 3, 2012
  • binand

    Nov. 24, 2012
  • HanaSoukalov

    Sep. 30, 2011
  • cosmos316

    May. 10, 2011

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.

Views

Total views

20,453

On Slideshare

0

From embeds

0

Number of embeds

320

Actions

Downloads

954

Shares

0

Comments

0

Likes

18

×