ì

 
Scrum   -­‐Abhijit  Mahajan    
-­‐Neelam  Agrawal  
an  agile  development  process  methodology    
 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