Using  Scrum  with  Jira  and  Greenhopper  

A  behind  the  scenes  look  at  scrum  and  Jira  in  action  

Michelle  Lorenz,  Itslearning  

 

 

Introduction  

•  Whoami:  Michelle  Lorenz,  QA  Manager,  Educational  Software  company  based  in  Norway  

•  Have  been  using  scrum  at  itslearning  for  several  years  

•  Kept  finding  scrum  is  ‘nice  in  theory,  but  doesn’t  work  in  practice’  

•  Six  months  ago  we  switched  to  Jira  

•  This  is  our  story  

Scrum  in  a  Nutshell  

•  Software  development  broken  into  short  cycles  (sprints)  

•  At  end  of  each  sprint,  software  is  test-­‐complete  and  in  a  release-­‐able  state  

•  A  release  comprises  one,  or  several  sprints  

•  Team  consists  of  team  lead,  developers  and  testers  

Start of Sprint

Everyday  challenges  

•  How  to  estimate  user  stories  

•  Managing  user  stories,  development,  and  testing  in  Greenhopper  

•  “Why  doesn’t  the  burndown  chart  work?”  

•  Incomplete  work  at  end  of  sprint  

•  Maintaining  quality  

•  “I  have  nothing  to  do”  

Sprint  in  Greenhopper  

Managing  the  burn-­‐down  chart  

During Sprint: Testers find a bug, now what?

Managing  quality  with  Scrum  

•  Three  scenarios:  1.  Team  finds  a  bug  related  to  a  current  user  story  in  sprint  

2.  Team  finds  a  bug  not  in  production  and  not  related  to  any  current  user  stories  

3.  Team  finds  a  bug  which  exists  in  production  

3: Team finds a bug which exists in production

•  Fixing  bugs  is  BAU  •  But,  product  manager  drives  development  for  sprints  

•  Once  team  signs  off  on  sprint,  new  work  shouldn’t  be  added  

•  Where  does  team  get  time  to  fix  bugs?  

Bug  fix  time  box  

•  Set  aside  15%  of  available  sprint  time  to  fixing  bugs  

•  Have  a  common  project  in  Jira  to  manage  all  production  bugs  (may  include  support  bugs)  –  the  bug  backlog  

 

“I  have  nothing  to  do”  

•  What  do  testers  do  at  the  start  of  the  sprint,  when  there  is  nothing  to  test?  

•  What  should  developers  do  during  last  days  of  sprint?  

•  What  happens  when  team  members  run  out  of  work?  

Sprint  Review:  There  is  unaccepted  work  

1.  Consider  working  overtime  

2.  Accept  as-­‐is:  Cost  of  quality  3. Move  to  next  sprint  as  first  priority  

Unaccepted  user  stories  should  be  the  exception  

•  Better  to  have  un-­‐started  user  stories,  then  started  but  not  completed  user  stories  

Release  and  Repeat  

•  Theory:  At  end  of  sprint,  all  work  can  be  released  into  production  

•  Practice:  Final  UAT  or  regression  test  is  required  

Springboard  to  knowledge