Introduction to scrum & agile

Uploaded on


More in: Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Scrum  Essen+als   Presented  by  Riad  Bacchus   LinkedIn/Riad  Bacchus  
  • 2. Overview  •  Scrum  Overview     How  does  it  all  work?  •  Scrum  Planning     How  do  we  plan  the  project?  •  Scrum  Roles       Who’s  responsible?  •  Scrum  Ar+facts       What  documents  are  needed?  •  Scrum  Mee+ngs     What  mee9ngs  drive  Scrum?  
  • 3. Scrum  Overview  •  Developed  in  1993    •  Scrum  is  one  of  several  Agile  Methodologies  •  Scrum  is  part  of  the  Agile  Alliance  •  Has  been  used  on  thousands  of  projects  •  Used  internally  by  various  MicrosoN  teams  •  Can  manage  projects  of  2  -­‐  3000  team  members  
  • 4. Scrum  Cycles   Program 2-n months Project 2-n months Release 2-6 months Sprint 30 days Daily Scrum daily
  • 5. Project  Success  Decline  Over  Time   This  graph  indicates  the  sharp  decline  in  project  success  the  longer  a   project  runs  without  shipping  a  release.       1-­‐6  months  seems  to  be  the  sweet  spot.  
  • 6. Working  vs.  Released  SoNware   Sprint  1   Sprint  2   Sprint  3   Sprint  4   (Normal)   (Normal)   (Normal)   (Release)   Sprint  5   Sprint  6   Sprint  7   Sprint  8   (Normal)   (Release)   (Normal)   (Release)  •  During  normal  sprints,  working  soNware  is   “DONE”  but  might  not  be  “released”.  •  During  release  sprints,  working  soNware  is   deployed.  
  • 7. Scrum  Planning  •  A  Scrum  project  is  planned  up  front  &  as  we  go.  •  Up  front?   – Set  expecta+ons  based  on  “ini+al”  scope.   – Develop  a  priori+zed  product  backlog.   – Assign  “order  of  magnitude”  es+mates.  (+75%/-­‐25%)   – Define  desired  +ming  for  produc+on  releases.   – Es+mate  resources  needed.   – Es+mate  sprint  count  •  As  we  go!   – At  the  start  of  each  sprint,  plan  30  days  of  scope.   – Refine  es+mates,  priori+es  and  product  backlog.  
  • 8. Scrum  Roles   ScrumMaster  Product  Owner  •  Establish  vision   •  Teach  /  Coach  Scrum  •  Set  Sprint  Goals   •  Manage  Process  •  Set  Priori+es   •  Protect  Team  •  Owns  the  Product  Backlog   •  Enforce  Rules   •  Remove  Blocks   •  Facilitate  Mee+ngs  Stakeholder   Team  •  Observe   •  Organize  work  •  Advise   •  Develop  product   •  Communicate  issues  &  progress  
  • 9. Scrum  Ar+facts   Sprint  Backlog  •  Product  Backlog   List  of  requirements   •  Decomposed  task  list  •  Owned  by  Product  Owner   •  Driven  by  a  por+on  of  Product  •  Anybody  can  add  to  it   Backlog   •  Owned  by  Team  •  Priori+zed  by  business  value   •  Only  Team  modifies  it  •  Can  change  without  affec+ng   the  ac+ve  Sprint  Sprint  Goal   Blocks  List  •  One  sentence  summary   •  List  of  blocks  &  pending  •  Defined  by  Product  Owner   decisions  •  Accepted  by  Team   •  Owned  by  ScrumMaster   •  Blocks  stay  on  list  un+l  resolved   Increment •  Version of the product •  Potentially shippable •  Working functionality •  Tested & documented according to project definition of “DONE”
  • 10. Sample  Product  Backlog  •  The  scope  list   •  A,  B,  C  feature  dis+nc+on  •  Priori+zed  by     •  Rough  es+mates  help  size  the   business  value   sprints  
  • 11. Sample  Sprint  Backlog  •  Granular  tasks     (2-­‐40  hours  each)  •  Assigned  to  team  members  •  Es+mates  adjusted  daily     by  team  •  Managed  by  the  team  
  • 12. Sample  Burndown  Chart  •  Provides  candid  transparency  •  Printed  daily  •  Posted  publicly  •  May  be  bumpy  
  • 13. Scrum  Mee+ngs  Sprint  Planning  -­‐  A   Daily  Scrum  •  Time-­‐boxed:  <  4  hours   •  Time-­‐boxed:  <  15  minutes  •  Run  by  ScrumMaster   •  Run  by  ScrumMaster  •  Declare  Sprint  Goal   •  Aoended  by  all  •  Top  of  Product  Backlog  presented   •  Stakeholders  do  not  speak   by  P.O.   •  Same  +me/place  daily  •  Team  asks  ques+ons  &  selects   •  Answer  3  ques+ons:   topmost  features   1)  What  I  did  yesterday  Sprint  Planning  -­‐  B   2)  What  I’ll  do  today  •  Time-­‐boxed:  <  4  hours   3)  What’s  in  my  way  •  Run  by  ScrumMaster   •  Sprint  Backlog  updated  •  Team  decomposes  features  into  a   •  ScrumMaster  updates  blocks   Sprint  Backlog  •  Team  adjusts  +/-­‐  features  by  task   es+mates  against  sprint  capacity   Sprint  Retrospec+ve  Sprint  Review   •  Time-­‐boxed:  1-­‐2  hours  •  Time-­‐boxed:  <  4  hours   •  Run  by  ScrumMaster  •  Run  by  ScrumMaster   •  Aoended  by  Team  and  P.O.  •  Aoended  by  all   •  Discuss  process  improvements,  •  Team  demonstrates  increment   wins  and  losses  •  All  discuss   •  Adjust  process  
  • 14. Scrum  on  a  Page
  • 15. Review  •  Scrum  Overview     How  does  it  all  work?  •  Scrum  Planning     How  do  we  plan  the  project?  •  Scrum  Roles       Who’s  responsible?  •  Scrum  Ar+facts       What  documents  are  needed?  •  Scrum  Mee+ngs     What  mee9ngs  drive  Scrum?  
  • 16. Roles  Q&A  •  What  if  the  client  doesn’t  know  how  to  be  a  Product  Owner?   –  It  is  common  for  a  client  to  be  willing,  but  inexperienced  as  a  P.O.    In  this  case,   the  ScrumMaster  must  lead  the  client  through  the  tasks  of  building  a  Product   backlog,  priori+zing  and  elabora+ng  features.    Remember,  teaching  is  part  of   the  duty  of  a  ScrumMaster.    Leading  the  P.O.  through  the  mo+ons  ini+ally  is  a   great  way  to  teach.   –  The  ScrumMaster  needs  to  set  expecta+ons  with  the  client  as  to  their  role  in   the  success  of  the  project.       –  Regardless  of  Agile  or  Tradi+onal  project  methods,  a  project  that  doesn’t  have   strong  support  and  par+cipa+on  from  the  key  stakeholders  is  very  likely  to  fail.   –  If  the  client  refuses  to  accept  some  or  all  of  the  du+es  of  Scrum’s  version  of  a   P.O.,  the  ScrumMaster  may  proxy  for  the  Product  Owner.    However,  this  adds   risk,  and  fails  to  truly  empower  the  client.  •  What  if  the  client  or  a  team  member  keeps  breaking  the  rules?   –  The  ScrumMaster’s  primary  duty  is  to  protect  the  team’s  +me  and  focus  to   achieve  stated  project  goals.    The  ScrumMaster  must  seriously  address  any   disregard  for  the  process.  
  • 17. Product  Backlog  Q&A  •  What  does  Neudesic  use  to  manage  a  Product  Backlog   –  TFS   –  (OR)  A  spreadsheet  Product  Backlog  (posted  to  SharePoint)  •  Can  Neudesic  create  the  Product  Backlog  for  the  client?   –  Preferably  not.      But  in  many  cases,  we’ll  need  to  help  teach  the  client  how  to  maintain  a   backlog.   –  In  the  absence  of  a  strong  client  leader  who  can  be  assigned  the  clear  “Product  Owner”   role,  we  have  no  choice  but  to  serve  as  the  Product  Owner.  •  What  should  the  Product  Backlog  contain?   –  Item  Name   –  Priority  (according  to  business  value)   –  User  Story  (1-­‐2  paragraphs  descrip9on)   –  Status  (New,  Approved,  In  Progress,  Completed,  Cancelled)   –  Sprint  Number  •  When  can  the  Product  Backlog  change?   –  Any  +me  (except  for  sprint  planning  day).   –  Refine  es+mates,  priori+es  and  product  backlog.  
  • 18. Product  Backlog  Q&A  cont’d  •  Does  the  Product  Backlog  ever  contain  items  other  than  product  features?   –  Yes.    ONen,  major  tasks  (40  hours+)  are  priori+zed  in  the  backlog  even  if  they   do  not  strictly  represent  features.    System  Stories  are  used  to  capture  security,   performance  and  infrastructure  requirements.   –  Examples:  Integrate  SharePoint  with  MIIS,  User  Training  Guide.  •  Don’t  changes  to  the  backlog  affect  project  scope?   –  Yes.    In  some  cases  the  changes  represent  a  small  impact  to  overall  project   outcome.    In  others,  the  changes  will  require  a  revisit  of  the  program/project/ release  planning  constraints  and  es+mates.   –  If  the  Product  Owner  makes  significant  changes  (addi+ons)  to  the  Product   Backlog,  this  should  force  a  conversa+on  between  the  ScrumMaster  and  the   Product  Owner  resesng  expecta+ons.       –  However,  this  should  be  done  in  the  spirit  of  “harnessing  change”  vs.   “preven+ng  change”.  
  • 19. Sprint  Backlog  Q&A  •  When  is  the  Sprint  Backlog  created?   –  During  the  sprint  planning  mee+ng  (day  1  of  each  sprint).  •  How  is  the  Sprint  Backlog  different  from  the  Product  Backlog?   –  It  contains  “tasks”,  whereas  the  Product  Backlog  primarily  contains  priori+zed   features  and  major  efforts.   –  The  tasks  it  contains  are  usually  “decomposed”  down  to  8-­‐40  hour  efforts.   –  The  Team  creates  and  maintains  the  Sprint  Backlog.    Only  they  are  allowed  to   add  or  remove  tasks.  •  How  does  the  team  know  enough  on  day  1  of  the  Sprint  to  accurately   es+mate  tasks  in  the  Sprint  Backlog?   –  They  might  not.    But,  their  job  in  the  sprint  planning  mee+ng  is  to  find  out   (and  write  down)  enough  clarifying  details  to  be  accurate  enough  in  their   es+ma+ons  for  the  purposes  of  a  30-­‐day  planning  window.   –  Depending  on  how  well  defined  the  sprint  features  are,  the  team  may  choose   not  to  “fill  up  the  sprint”  en+rely,  allowing  some  +me  do  deal  with  the   unknown.“  
  • 20. Sprint  Backlog  Q&A  cont’d  •  Can  the  Team  add  items  to  the  Sprint  Backlog  during  the  Sprint?   –  Yes,  the  team  is  free  to  add  tasks  to  the  Sprint  Backlog  throughout  the  Sprint,   so  long  as  they  are  directly  associated  with  mee+ng  the  stated  sprint  goal  and   the  specific  features  that  were  selected  from  the  Product  Backlog.   –  No,  the  team  is  not  free  to  silently  select  addi+onal  features  from  the  product   backlog  during  the  Sprint.    They  are  encouraged  to  ask  the  Product  Owner  for   addi+onal  features  if  they  feel  there  is  room  for  more.  •  Who  assigns  team  members  to  tasks?   –  The  Team  works  out  its  own  assignments  during  Sprint  Planning.   –  The  Team  can  at  any  +me  adjust  assignments  to  op+mize  outcomes.  •  How  detailed  must  Sprint  Backlog  items  be?   –  They  should  be  broken  down  into  tasks  discrete  enough  for  the  team  to  see   how  they’ll  accomplish  the  selected  Sprint  scope.   –  A  good  rule  of  thumb  is:  tasks  of  8-­‐24  hour  dura+on.   –  Key  mee+ngs  should  be  included  (e.g.  design  workshops  2+  hours,  integra+on   work  sessions  2+  hours)  as  they  tend  to  add  up  when  all  team  members  are   present.  
  • 21. Further  Reading  •  Agile  SoNware  Development  with  Scrum   2002,  Pren+ce  Hall,  Ken  Schwaber,  Mike  Beedle.   (#1  read  for  anyone  serious  about  Scrum)  •  Agile  Project  Management  with  Scrum   2004,  MicrosoN  Press,  Ken  Schwaber.   (A  bit  more  fluffy,  but  has  a  lot  of  case  studies)  •  Agile  &  Itera+ve  Development   2004,  Pearson  Educa+on,  Craig  Larman.   (#1  read  to  introduce  and  compare  Agile  methods)  •  Agile  SoNware  Development   2002,  Pearson  Educa+on,  Alistair  Cockburn  .   (Provides  the  science  and  the  “why’s”  of  Agile  methods)