Introduction to scrum & agile
Upcoming SlideShare
Loading in...5

Like this? Share it with your network


Introduction to scrum & agile






Total Views
Views on SlideShare
Embed Views



1 Embed 53 53



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Introduction to scrum & agile Presentation Transcript

  • 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)