ì  Scrum  an  agile  development  process  methodology  

-­‐Abhijit  Mahajan    -­‐Neelam  Agrawal    

Introduction  

ì  Scrum  is  an  agile  so<ware  development  methodology  

ì  It  is  an  itera>ve  and  incremental  methodology    ì  for  so<ware  projects  and  product-­‐  or  applica>on-­‐

development  

ì  Projects  progress  via  a  series  of  itera>ons    ì  called  sprints    

ì  which  are  usually  2-­‐4  weeks  long  

ì  A  typical  scrum  team  has  between  five  and  nine  people    ì  but  Scrum  projects  can  easily  scale  into  the  hundreds  

History  

History  

ì  1993-­‐Jeff  Sutherland,  John  Scumniotales  and  Jeff  McKenna,  came  up  with  an  approach  at  Easel  Corpora>on  ì  first  to  refer  it  using  the  single  word  Scrum.  

ì  In  1996,  Sutherland  and  Schwaber  jointly  presented  a  paper  describing  the  Scrum  method  at  the  Business  Object  Design  and  Implementa>on  Workshop    ì  held  as  part  of  OOPSLA  ’95  in  Aus>n,  Texas.  

ì  1998-­‐  Ken,  Jeff,  et  al  came  up  with  “Scrum  a  pa[ern  language  for  hyperproduc>ve  so<ware  development”  

ì  In  2001,  Schwaber  worked  with  Mike  Beedle  to  describe  the  method  in  the  book  Agile  with  Scrum  

SCRUM  Methodology  

Scrum  &  Rugby  

ì  The  SCRUM  methodology  shares  many  characteris>cs  with  the  sport  of  Rugby  :  ì  The  context  is  set  by                    playing  field                    (environment)  and                      rugby  rules  (controls).  ì  The  primary  cycle  is  moving  the  ball  forward.  ì  Rugby  evolved  from  breaking  soccer  rules  -­‐  adap>ng  to  

the  environment.  ì  The  game  does  not  end  un>l  environment  dictates  

(business  need,  compe>>on,  func>onality,  >metable).  

Scrum  phase  list  

ì  Pregame  ì  Planning  ì  System  Architecture/High  Level  Design  

ì  Game  ì  Sprints  (Concurrent  Engineering)  ì  Develop  (Analysis,Design,Develop)  ì  Wrap  ì  Review  ì  Adjust  

ì  Postgame  ì  Closure  

SCRUM  Phases  (1)  

ì  Pregame  ì  Planning  :    

ì  Defini>on  of  a  new  release  based  on  currently  known  backlog,  along  with  an  es>mate  of  its  schedule  and  cost.    

ì  If  a  new  system  is  being  developed,  this  phase  consists  of  both  conceptualiza>on  and  analysis.    

ì  If  an  exis>ng  system  is  being  enhanced,  this  phase  consists  of  limited  analysis.  

ì  Architecture  :    ì  Design  how  the  backlog  items  will  be  implemented.    ì  This  phase  includes  system  architecture  modifica>on  and  

high  level  design.  

SCRUM  Phases  (2)  

ì  Game  ì  Development  Sprints  :    

ì  Development  of  new  release  func>onality,  with  constant  respect  to  the  variables  of  >me,  requirements,  quality,  cost,  and  compe>>on.  

ì  Interac>on  with  these  variables  defines  the  end  of  this  phase.    

ì  There  are  mul>ple,  itera>ve  development  sprints,  or  cycles,  that  are  used  to  evolve  the  system.  

ì  Postgame  ì  Closure  :    

ì  Prepara>on  for  release,  including  final  documenta>on,  pre-­‐release  staged  tes>ng,  and  release.  

Planning  (1)  

ì  Development  of  a  comprehensive  backlog  list.  

ì  Defini>on  of  the  delivery  date  and  func>onality  of  one  or  more  releases.  

ì  Selec>on  of  the  release  most  appropriate  for  immediate  development.  

ì  Mapping  of  product  packets  (objects)  for  backlog  items  in  the  selected  release.  

ì  Defini>on  of  project  team(s)  for  the  building  of  the  new  release.  

Planning  (2)  

ì  Assessment  of  risk  and  appropriate  risk  controls.  

ì  Review  and  possible  adjustment  of  backlog  items  and  packets.  

ì  Valida>on  or  reselec>on  of  development  tools  and  infrastructure.  

ì  Es>ma>on  of  release  cost,  including  development,  collateral  material,  marke>ng,  training,  and  rollout.  

ì  Verifica>on  of  management  approval  and  funding.  

Architecture/High  Level  Design  (1)  

ì  Review  assigned  backlog  items.  

ì  Iden>fy  changes  necessary  to  implement  backlog  items.  

ì  Perform  domain  analysis  to  the  extent  required  to  build,  enhance,  or  update  the  domain  models  to  reflect  the  new  system  context  and  requirements.  

ì  Refine  the  system  architecture  to  support  the  new  context  and  requirements.  

Architecture/High  Level  Design  (2)  

ì  Iden>fy  any  problems  or  issues  in  developing  or  implemen>ng  the  changes  

ì  Design  review  mee>ng,  each  team  presen>ng  approach  and  changes  to  implement  each  backlog  item.    

ì  Reassign  changes  as  required.  

Sprint  (1)  

ì  A  sprint  is  the  basic  unit  in  Scrum  ì  lasts  between  one  week  and  one  month  

ì  Each  sprint  is  preceded  by  a  mee>ng  ì  where  the  tasks  for  the  sprint  are  ini>ated  for  the  sprint  

goal  

ì  The  work  items  come  from  the  product  backlog  ì  which  is  a  priori>zed  list  of  requirements  

ì  During  the  sprint  planning  mee>ng,  the  Product  Owner  informs  the  group  of  the  items  in  the  product  backlog  that  needs  to  be  completed    ì  the  ones  with  the  highest  priority    

Sprint  (2)  

ì  The  group  then  determines  how  much  of  this  they  can  commit  to  complete  during  the  next  sprint  ì   and  records  this  in  the  sprint  backlog  

ì  During  a  sprint,  no  one  is  allowed  to  change  the  sprint  backlog  ì   which  means  that  the  requirements  are  frozen  for  

that  sprint  ì   if  requirements  are  not  completed  for  any  reason  

they  are  le<  out  and  returned  to  the  product  backlog  

More  Game  phase(1)  

ì  Develop:    ì  Defining  changes  needed  for    

ì  the  implementa>on  of  backlog  requirements  into  packets,  opening  the  packets,  performing  domain  analysis  

ì  designing,  developing,  implemen>ng,  tes>ng,  and  documen>ng  the  changes.    

ì  Development  consists  of  the  micro  process  of  discovery,  inven>on,  and  implementa>on.  

ì  Wrap:    ì  Closing  the  packets,  crea>ng  an  executable  version  of  

changes  and  how  they  implement  backlog  requirements.  

More  Game  phase  (2)  

ì  Review:    ì  All  teams  mee>ng  to  present    

ì  work  and  review  progress  ì  raising  and  resolving  issues  and  problems    ì  adding  new  backlog  items    

ì  Risk  is  reviewed  and  appropriate  responses  defined.  

ì  Adjust:  ì  Consolida>ng  the  informa>on  gathered  from  the  review  

mee>ng  into  affected  packets,  including  different  look  and  feel  and  new  proper>es.  

Closure  

ì  When  the  management  team  feels  that  the  variables  of  >me,  compe>>on,  requirements,  cost,  and  quality  concur  for  a  new  release  to  occur,  they  declare  the  release  “closed”  and  enter  this  phase.    

ì  This  phase  prepares  the  developed  product  for  general  release.  

ì  Integra>on,  system  test,  user  documenta>on,  training  material  prepara>on,  and  marke>ng  material  prepara>on  are  among  closure  tasks.  

Roles  

The  various  roles  in  Scrum  team  

ì  Core  Roles  ì  Product  Owner  ì  Development  Team  ì  Scrum  Master  

ì  Ancillary  roles  ì  Stakeholders  (customers,  vendors)  ì  Managers  

Product  Owner  

ì  The  Product  Owner  represents  the  voice  of  the  customer    ì  is  accountable  for  ensuring  that  the  Group  delivers  

value  to  the  business  ì  Writes  customer-­‐centric  items  (user  stories),    

ì  priori>zes  them    ì  and  adds  them  to  the  product  backlog  

ì  Scrum  groups  should  have  one  Product  Owner  ì  She  may  also  be  a  member  of  the  Management  Group  ì   It  is  recommended  that  this  role  not  be  combined  

with  ScrumMaster  

Development  Team  

ì  Responsible  for  delivering  poten>ally  shippable  product  increments  at  the  end  of  each  Sprint.  

ì  It  is  made  up  of  people  with  cross-­‐func>onal  skills    ì  who  do  the  actual  work    

ì  analyze,  design,  develop,  test,  technical  communica>on,  document,  etc    

ì  It  is  self-­‐organizing  ì   even  though  they  may  interface  with  project  

management  organiza>ons  (PMOs).  

Scrum  Master  

ì  Scrum  Master  is  accountable  for  removing  impediments  to  the  ability  of  the  group  to  deliver  the  sprint  goal/deliverables.    

ì  She  acts  as  a  buffer  between  the  group  and  any  distrac>ng  influences.    

ì  The  Scrum  Master  is  the  enforcer  of  rules.    ì  A  key  part  of  the  role  is  to  protect  the  Development  

Team  and  keep  it  focused  on  the  tasks  at  hand.  

Ancillary  Roles  

ì  The  ancillary  roles  in  Scrum  groups  are  those  with  no  formal  role  and  infrequent  involvement  in  the  Scrum  process  ì  but  nonetheless,  must  be  taken  into  account.  

ì  Stakeholders  (customers,  vendors):    ì  People  who  enable  the  project  and  for  whom  the  project  

produces  the  agreed-­‐upon  benefit[s]    ì  that  jus>fy  its  produc>on  

ì   They  are  only  directly  involved  in  the  process  during  the  sprint  reviews  

ì  Managers:    ì  People  who  control  the  environment  

Meetings  Overview  

Meetings  

The  following  is  a  list  of  meeCngs  in  Scrum  development  

ì  Daily  Scrum  

ì  Backlog  grooming:  storyCme  

ì  Scrum  of  Scrums  

ì  Sprint  planning  meeCng  

ì  Sprint  review  meeCng  

ì  Sprint  retrospecCve  

Daily  Scrum  (1)  

ì  Happens  each  day  during  the  sprint  ì   is  a  project  status  mee>ng    

ì  This  mee>ng  has  specific  guidelines:  ì  The  mee>ng  starts  precisely  on  >me  ì  All  are  welcome,  but  normally  only  the  core  roles  

speak  ì  The  mee>ng  length  is  set  to  15  mins  ì  The  mee>ng  should  happen  at  the  same  loca>on  

and  same  >me  every  day  

Daily  Scrum  (2)  

ì  During  the  mee>ng,  each  group  member  answers  three  ques>ons  ì  What  have  you  done  since  yesterday?  ì  What  are  you  planning  to  do  today?  ì  Any  impediments/stumbling  blocks?  

ì  Scrum  Master  should  facilitate  resolu>on  of  these  impediments,  although  the  resolu>on  should  occur  outside  the  Daily  Scrum  itself  to  keep  it  under  15  minutes.  

Backlog  grooming:  storytime  

ì  This  is  the  process  of  ì  es>ma>ng  the  exis>ng  backlog  using  effort/points  ì  refining  the  acceptance  criteria  for  individual  stories  ì   and  breaking  larger  stories  into  smaller  stories  

ì  Mee>ngs  should  not  be  longer  than  an  hour  

ì  Mee>ng  does  not  include  breaking  stories  into  tasks  

ì  Group  can  decide  how  many  mee>ngs  are  needed  per  week.  

Scrum  of  scrums  

ì  Each  day  normally  a<er  the  Daily  Scrum.  

ì  These  mee>ngs  allow  clusters  of  groups  to  discuss  their  work,  focusing  especially  on  areas  of  overlap  and  integra>on.  

ì  A  designated  person  from  each  group  a[ends.  

ì  The  agenda  will  be  the  same  as  the  Daily  Scrum,  plus  the  following  four  ques>ons:  ì  What  has  your  group  done  since  we  last  met?  ì  What  will  your  group  do  before  we  meet  again?  ì  Is  anything  slowing  your  group  down  or  gemng  in  their  way?  ì  Are  you  about  to  put  something  in  another  group’s  way?  

Sprint  planning  meeting(1)  

ì  Takes  place  at  the  beginning  of  the  sprint  cycle  

ì  The  Sprint  Planning  Mee>ng  is  a[ended  by    ì  the  product  owner  ì  Scrum  Master  ì  the  en>re  Scrum  Team.    

ì  There  are  two  defined  ar>facts  resul>ng  from  this  mee>ng:  ì  A  sprint  goal    ì  A  sprint  backlog  

ì  A  sprint  goal  is  a  short,  one-­‐  or  two-­‐sentence,  descrip>on  of  what  the  team  plans  to  achieve  during  the  sprint.    ì  It  is  wri[en  collabora>vely  by  the  team  and  the  product  owner  

Sprint  planning  meeting(2)  

ì  The  team  asks  enough  ques>ons  so  that  they  can  turn  a  high-­‐level  user  story  of  the  product  backlog  into  the  more  detailed  tasks  of  the  sprint  backlog.  

ì  Sprint  Backlog  is  prepared  with  details  of  the  >me  it  will  take  to  do  a  par>cular  work  

ì  Iden>fy  and  communicate  how  much  of  the  work  is  likely  to  be  done  during  the  current  sprint  

ì  Eight  hour  >me  limit  ì  (1st  four  hours)  Product  Owner  +  Group:  dialog  for  

priori>zing  the  Product  Backlog  ì  (2nd  four  hours)  Group  only:  hashing  out  a  plan  for  the  

Sprint,  resul>ng  in  the  Sprint  Backlog  

Sprint  review  meeting(1)  

ì  Held  at  the  end  of  each  sprint  during  which  the  Scrum  team  shows  what  they  accomplished  during  the  sprint.    

ì  Typically  this  takes  the  form  of  a  demo  of  the  new  features.  

ì  It  is  inten>onally  kept  very  informal,  typically  with  rules  forbidding  the  use  of  PowerPoint  slides.  

ì  A  sprint  review  mee>ng  should  not  become  a  distrac>on  or  significant  detour  for  the  team  ì  rather,  it  should  be  a  natural  result  of  the  sprint  

Sprint  review  meeting(2)  

ì  Par>cipants  in  the  sprint  review  typically  include    ì  the  Product  Owner  ì  the  Scrum  team    ì  the  ScrumMaster  ì  management,  customers,  and  developers.  

ì  The  project  is  assessed  against  the  sprint  goal  determined  during  the  Sprint  planning  mee>ng.    

ì  It  is  important  that  the  team  has  achieved  the  overall  goal  of  the  sprint.  

Sprint  Review  Meeting  (3)  

Sprint  retrospective  

ì  The  sprint  retrospec>ve  is  usually  the  last  thing  done  in  a  sprint.    ì  Many  teams  do  it  immediately  a<er  the  sprint  review.  

ì  This  is  a  period  at  the  end  of  each  sprint  to  deliberately  reflect  on  how  the  team  is  doing  and  to  find  ways  to  improve.    

ì  The  en>re  team,  including  both  the  ScrumMaster  and  the  product  owner  par>cipate  in  this  mee>ng.  

ì  It  has  three  hour  >me  limit  

ì  Two  main  ques>ons  asked  in  the  sprint  retrospec>ve  are:    ì  What  went  well  during  the  sprint?    ì  What  could  be  improved  in  the  next  sprint?  

Artifacts  

ì  Product  Backlog  

ì  Sprint  Backlog  

ì  Burndown  Charts  

Product  Backlog(1)  

ì  It  is  an  ordered  list  of  "requirements”  maintained  for  a  product.  

ì  These  items  are  ordered  by  the  Product  Owner  based  on  considera>ons  like  risk,  business  value,  dependencies,  date  needed,  etc.    

ì  The  values  in  product  backlog  are  o<en  stated  in  story  points  using  a  rounded  Fibonacci  sequence.    

Product  Backlog(2)  

ì  Those  es>mates  help  the  Product  Owner  to  gauge  the  >meline  and  may  influence  ordering  of  backlog  items.  

ì  The  Product  Backlog,  and  business  value  of  each  listed  item  is  the  responsibility  of  the  Product  Owner.    

ì  The  es>mated  effort  to  complete  each  backlog  item  is  determined  by  the  Development  Team.  

Product  Backlog  

Sprint  Backlog(1)  

ì  It  is  the  list  of  work  the  Development  Team  must  address  during  the  next  sprint.    

ì  The  list  is  derived  by  selec>ng  stories/features  from  the  top  of  the  product  backlog.    

ì  The  Development  Team  should  keep  in  mind  the  velocity  of  its  previous  Sprints  when  selec>ng  stories/features  for  the  new  sprint.  

Sprint  Backlog(2)  

ì  The  stories/features  are  broken  down  into  tasks  by  the  Development  Team  ì  should  normally  be  between  four  and  sixteen  hours  of  

work  

ì  Tasks  on  the  sprint  backlog  are  never  assigned;    ì  rather,  tasks  are  signed  up  for  by  the  group  members  as  

needed  during  the  daily  scrum.  

ì  O<en  an  accompanying  task  board  is  used  to  see  and  change  the  state  of  the  tasks  of  the  current  sprint,    ì  like  “not  checked  out”,  “checked  out”  and  “done”.  

Sprint  Backlog  

Burndown  Charts  

ì  Sprint  burndown  chart  ì  It  is  a  publicly  displayed  chart  (updated  daily)showing  

remaining  work  in  the  sprint  backlog.    ì  It  gives  a  simple  view  of  the  sprint  progress.    

ì  Release  burndown  chart    ì  shows  the  amount  of  work  le<  to  complete  the  target  

commitment  for  a  Product  Release  

ì  Alterna>ve  release  burndown  chart  ì  which  basically  does  the  same,  but  clearly  shows  scope  

changes  to  Release  Content,  by  resemng  the  baseline.  

Burndown  Charts  

Modifications:  Scrum-­‐ban(1)  

ì  Scrum-­‐ban  is  a  produc>on  model  based  on  Scrum  and  Kanban.    

ì  It  is  suited  for  maintenance  projects  or  (system)  projects  with  frequent  and  unexpected  user  stories  or  programming  errors.    

ì  In  such  cases  the  >me-­‐limited  sprints  of  the  Scrum  model  are  of  no  appreciable  use,  but  Scrum’s  daily  mee>ngs  and  other  prac>ces  can  be  applied.    

ì  Visualiza>on  of  the  work  stages  and  limita>ons  for  simultaneous  unfinished  user  stories  and  defects  are  familiar  from  the  Kanban  model.    

Modifications:  Scrum-­‐ban(2)  

ì  Using  these  methods,  the  group’s  workflow  is  directed  in  a  way    ì  that  allows  for  minimum  comple>on  >me  for  each  user  

story  or  programming  error,    ì  and  on  the  other  hand  ensures  each  group  member  is  

constantly  employed.  

ì  The  major  differences  between  Scrum  and  Kanban  are  ì  in  Scrum,  work  is  divided  into  sprints  that  last  a  certain  

amount  of  >me  ì  whereas  in  Kanban  the  workflow  is  con>nuous.  

Advantages  (1)  

ì  The  SCRUM  methodology  is  designed  to  be  quite  flexible  throughout.  

ì  It  provides  control  mechanisms  for  planning  a  product  release  and  then  managing  variables  as  the  project  progresses.    

ì  This  enables  organiza>ons  to  change  the  project  and  deliverables  at  any  point  in  >me,  delivering  the  most  appropriate  release.  

ì  The  SCRUM  methodology  frees  developers  to  devise  the  most  ingenious  solu>ons  throughout  the  project,  as  learning  occurs  and  the  environment  changes.  

ì  Small,  collabora>ve  teams  of  developers  are  able  to  share  tacit  knowledge  about  development  processes.    

Advantages  (2)  

ì  Object  Oriented  technology  provides  the  basis  for  the  SCRUM  methodology.    

ì  Objects,  or  product  features,  offer  a  discrete  and  manageable  environment.    

ì  Procedural  code,  with  its  many  and  intertwined  interfaces,  is  inappropriate  for  the  SCRUM  methodology.    

ì  SCRUM  may  be  selec>vely  applied  to    procedural  systems  with  clean  interfaces    and  strong  data  orienta>on.  

Some  difficulties  

Get  set  go!  

References  

ì  Ken  Schwaber.  “SCRUM  Development  Process”  <h[p://home.hib.no/ai/data/master/mod251/2009/ar>cles/scrum.pdf>  

ì  h[p://en.wikipedia.org/wiki/Scrum_(development)  

ì  h[p://www.crisp.se/henrik.kniberg/presenta>ons/Scrum-­‐Intro-­‐Brief-­‐Henrik-­‐Kniberg.pdf