Agile-Scrum Methodology-An Introduction


Published on

This presentation introduces scrum, a very common agile methodology.

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

Agile-Scrum Methodology-An Introduction

  1. 1. Introduction to Agile with Scrum
  2. 2. Agenda  •  Short  introduc,on  to  Agile      •  Scrum   – Overview   – How  it  works   2  
  3. 3. Tradi4onal  So7ware  Project  Failures  •  Nearly  2  /  3  of  the  projects  are   significantly  over  budget  •  64%  of  the  features  in  a  product  are   rarely  used  •  An  average  project  exceeds  its  schedule   by  100%     3  
  4. 4. Main  Causes  •  Planning  for  comple4on  of  ac4vi4es  rather  than   features.  •  Progress  not  transparent  to  customers,  and  focus  on   ac4vi4es  leading  to  missing-­‐forgoRen  features.  •  Specializa4on  leading  to  island  culture  and  reduced   involvement.  •  Do  not  work  on  the  basis  of  client  priority,  but  o7en   technical.  Team  starts  late  with  important  business   needs  •  Ignore  uncertainty  (changing  insights  /  requests?)    
  5. 5. Limita4ons  of  Waterfall                                      "Waterfall"  project  approach  is  only  possible  if      •  Problem  is  clear;  •  Solu4on  is  known;  •  Technique  familiar;  •  Problem  has  not  changed;                                                                                                                •  A  sufficient  knowledge;  •  Priori4es  constant.  
  6. 6. Agile  Manifesto      
  7. 7. Suppor4ng  Agile  “Sentences”  1.  Our  highest  priority  is  to  sa4sfy  the  customer  through  early   and  frequent  delivery  of  valuable  so7ware.  2.  Deliver  working  so7ware  frequently,  from  a  couple  of   weeks  to  a  couple  of  months,  with  a  preference  for  the   shorter  4me  scale.  3.  Working  so7ware/product  is  the  primary  measure  of   progress.  4.  Welcome  changing  requirements,  even  late  in  development  5.  Business  people  and  developers  work  together  daily   throughout  the  project.  6.  Build  projects  around  mo4vated  individuals.    Give  them  the   environment  and  support  they  need,  and  trust  them  to  get   the  job  done.  
  8. 8. Agile  Methodologies  •  Extreme  Programming  (XP)  •  Scrum  •  Feature-­‐Driven  Development  (FDD)  •  Adap4ve  So7ware  Process  •  Crystal  Light  Methodologies  •  Dynamic  Systems  Development  Method   (DSDM)  •  Lean  Development  
  9. 9. Scrum     A scrum is a term from rugby.   Scrum is a way of re-start after minor violation, where a group of players tries to push the ball obtain control.
  10. 10. Scrum  Flow  
  11. 11. Sprints  •  Scrum  projects  consist  of  a  series  of  "sprints"  •  Typically  2-­‐4  weeks  in  length.  •  A  fixed  constant  length  gives  a  beRer  work  rate.  •  Features  are  designed,  built  and  tested  during  a   sprint.  •  Customer  can  not  change  job  during  a  sprint.  •  Have  a  sprint  goal.  A  brief  statement  about  the  focus   of  the  work  of  the   upcoming  sprint.  
  12. 12. Scrum  Framework      
  13. 13. Product  Owner  •  Is  the  voice  of  the  customer.  •  Defines  the  features  of  a  product.  •  Determines  the  release  date.  •  Responsible  for  the  profitability  of  a  product.  •  Its  mandate  is  to  make  decisions.  •  Priori4zes  the  product  features  based  on  market   value  •  Change  features  and  priority  every  itera4on,  if   desired.  •  Accepts  or  approves  work  results.
  14. 14. Team  •  Complete  (all  skills)  •  Self  and  self-­‐learning  •  No  permanent  jobs  •  5  to  9  people  •  Work  together,  not  individually.  •  Involved  •  Produc4ve  and  fun  •  Preferably,  cross-­‐func4onal.      
  15. 15. Scrum  Master  •  Is  not  a  project  manager!  Facilitates  the  team.  •  Responsible  for  the  importa4on  and  compliance  with  Scrum   values  and  prac4ces.  •  Solves  problems  for  the  progress  of  projects  iden4fied  by  the   team,  so  that  the  goal  of  Sprint  and  the  deliverables  are  met.  •  Ensures  that  the  team  is  fully  focused,  opera4onal  and   produc4ve.  •  Ensures  that  all  roles  and  func4ons  work  together.  •  Shields  the  team  from  external  disturbances  during  the  sprint.    
  16. 16. Scrum  Framework      
  17. 17. Sprint  Planning  
  18. 18. Sprint  Planning  
  19. 19. Daily  Scrum  •  Daily,  15  minutes,  standing.  •  Not  meant  to  solve  problems.  •  Anyone  outside  the  team  may  be  present,  only  team   members  are  ac4ve   part  (speaking).  •  Helps  to  avoid  unnecessary  mee4ngs  (e  g  weekly  progress   mee4ng)  •  Are  not  intended  to  state  the  progress  or  management.   –  What  did  you  do  yesterday? –  What  you  are  going  do  today? –  Are  there  any  restric4ons  that  the  comple4on  of  the  sprint   at  risk?
  20. 20. Daily  Scrum  
  21. 21. Sprint  Review(Demo)  •  The  team  presents  the  results  of  the  last   sprint  through  a  demonstra4on  of  the   func4onality  built.  •  Informal,  no  slides,  max  2  hours.  •  The  whole  team  takes  part  in  the   demonstra4on.  •  Stakeholders  and  managers  are  welcome  to   aRend.
  22. 22. Sprint  Retrospec4ve  •  Is  held  a7er  each  sprint  •  Consider  what  works  and  what  does  not  work.  •  Priori4za4on  of  the  improvement.  •  Ac4on  items  are  defined  to  ensure  that  real   improvements   takes  place  in  the  next  sprint  (s).  •  The  whole  team  takes  part  (Scrum  Master,  Product   Owner,  Team).  •  Dura4on  vary  depending  on  the  retrospec4ve   approach,  team  size,  length  sprint.•  Usually  30-­‐60  minutes  
  23. 23. Scrum  Framework  
  24. 24. Product  Backlog  •  The  requirements  •  To  Do  list  of  all  the  work  required  in  the  project.  •  Expressed  from  the  user  /  client.  •  Not  how  but  why.  •  By  priority  (by  product  owner.)  •  Itera4ve  (changes  ok,  for  each  sprint).  •  Visible.  •  Items  es4mated  effort  required  (by  team).  •  User story format: As <type of user> I want<some goal> so that <some business reason>.
  25. 25. Product  Backlog  
  26. 26. Sprint  Backlog  •  List  of  work  done  in  the  next  sprint.  •  Breakdown  of  features  into  tasks  (1-­‐16  hours).  •  Tasks  are  not  assigned  to  team  members.  (More   variety  and  crea4vity.  No  knowledge  islands)  •  Tasks  are  es4mated  by  the  team  with  Planning   Poker.  •  Tasks  are  picked  based  on  the  right  priori4es  and  the   skills  of  team  member.  •  Is  usually  visualized  by  a  Scrum  board
  27. 27. Planning  Poker  
  28. 28. Scrum  Board  
  29. 29. Scrum  Board  
  30. 30. Itera4on  Burn-­‐down  Chart  
  31. 31. Release  Burn-­‐down  Chart  
  32. 32. Defini4on  of  Done  •  Is  determined  by  the  team  •  Completed  work  must  meet  this  defini4on    •  Elements  to  consider  include:   –  Coding style –  Code comment –  Peer review –  Units tests –  Document –  Manual –  ???
  33. 33. Scrum  Flow  Summary  
  34. 34. Summary  •  Scrum  is  (almost)  Magic:   – Timely  feedback. – Focus  on  working  product. – Priori4ze  on  added  value. – Not  plan  ahead  in  detail. – Self-­‐management  and  responsibility. – Clear  roles  and  responsibili4es.  
  35. 35. To  be  con4nued…      
  1. A particular slide catching your eye?

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