Release planning in Scrum

5,649 views

Published on

A summary of what you may need to think about if, and I write if, you need to add Release Planning to scrum.

Published in: Technology, Business

Release planning in Scrum

  1. 1. 2013-­‐10-­‐24   Release  Planning  in  Scrum   Arne  Åhlander   Lean  and  Agile  Product  Management  Experts   What  do  you  know  about   Release  Planning?   1  
  2. 2. 2013-­‐10-­‐24   Arne  Åhlander   Lean  and  Agile  Product  Management  Experts   QuesHons  to  be  answered:   •  •  •  •  When  should  you  do  Release  Planning?   How  much  work  is  it?   Who  should  be  involved?   How  to  do  Release  Planning?   2  
  3. 3. 2013-­‐10-­‐24   Rough  Agenda   1.  Background   2.  Purpose  of  Release  Planning   3.  Input   –  What  do  we  need  before  we  can  start?   4.  Output   –  What  is  the  result  of  the  planning  acHviHes?   5.  ParHcipants   6.  Timebox   7.  Possible  ways    to  manage  Release  Planning   Background   3  
  4. 4. 2013-­‐10-­‐24   Planning   •  Important  learning  experience   •  CriHcal  in  developing  the  right  reflexes  in  an   organizaHon   •  Necessary  for  establishing  the  high-­‐level   architectural  design  of  a  complex  system   7   What  makes  planning  agile?   Is more focused on planning than the plan Encourages change Results in plans that are easily changed Is spread throughout the project 4  
  5. 5. 2013-­‐10-­‐24   The  Plan   •  •  •  •  Why  do  we  need  it?   How  shall  it  be  used?   How  detailed  shall  it  be?   The  reality  or  a  forecast?   What’s  a  good  plan?     •  A  good  plan  is  one  that  supports  reliable   decision-­‐making   •  Will  go  from   –  We’ll  be  done  in  the  fourth  quarter   –  We’ll  be  done  in  November   –  We’ll  be  done  November  7th   5  
  6. 6. 2013-­‐10-­‐24   TradiHonal  fixed  planning   follow ing the plan wh at h still app lon ens g to if re go. .. alit yc han ges ? Start 11   Paradox   …to  get  predictability  we  need  to  stop   predicHng…     …make  decisions  based  on  fact  not  forecasts…     …create  and  respond  to  feedback…   12   6  
  7. 7. 2013-­‐10-­‐24   ConHnuous  planning   Start 13   A  comparison   •  TradiHonal  planning   –  Leads  to  focus  on  meeHng   the  plan   –  Detailed  planning   up-­‐front   •  ConHnuous  planning   –  Leads  to  focus  on  value   creaHon   –  Detailed  planning  as  we   learn  more   14   7  
  8. 8. 2013-­‐10-­‐24   Rolling  (conHnuous)  Plan   •  •  •  •  Updated  frequently   Takes  changed  circumstances  into  account   Is  detailed  only  when  facts  allow  it   Is  detailed  as  we  learn  more   16   8  
  9. 9. 2013-­‐10-­‐24   The  detail  of  planning   Accuracy •  A  licle  effort  helps  a  lot   •  A  lot  of  effort  only  helps  a  licle  more   Effort 17   9  
  10. 10. 2013-­‐10-­‐24   Planning  onion   Planning  levels   10  
  11. 11. 2013-­‐10-­‐24   ose of g Purp n Planni e Releas To  get  rough  answers   •  When  can  this  be  done?   •  How  much  can  be  done  by  then?   11  
  12. 12. 2013-­‐10-­‐24   Release  burnup   Delivered features time Fixed  scope   Delivered features When will this much be done? Around middle of March time 12  
  13. 13. 2013-­‐10-­‐24   Fixed  scope   Delivered features When will this much be done? Around middle of March time Fixed  date   Delivered features Some of these All of these What will be done by February 1st? time 13  
  14. 14. 2013-­‐10-­‐24   Fixed  date  &  scope   Delivered features No. That is unrealistic. Can we get all of THIS done... ....by February 1st? time Fixed  date  &  scope   No. That is unrealistic. Delivered features We can get THIS much done by February 1st ...and the rest done by mid March. time 14  
  15. 15. 2013-­‐10-­‐24   An  Agile  approach  to  planning   Release Conditions of Satisfaction (user stories, budget, schedule) Feedback Release planning Iteration Feedback Conditions of Satisfaction (user stories, test) Iteration planning Development Product increment How  long  will  it  take   •  ...to  read  the  latest  Harry  Pocer  book?   •  ...to  drive  to  your  home  town?   15  
  16. 16. 2013-­‐10-­‐24   EsHmate  size;  derive  duraHon   Size Calculation Duration 300 kg Velocity = 20 300/20= 15 iterations Measures  of  size   • Traditional and agile measure size differently •  TradiHonal  measures   of  size   –  Lines  of  Code   –  FuncHon  Points   •  Agile  measures  of  size   –  Story  Points   –  Ideal  Days   16  
  17. 17. 2013-­‐10-­‐24   Story  points   •  The  ”bigness”  of  a  task   •  Influenced  by   –  How  hard  it  is   –  How  much  of  it  there  is   •  RelaHve  values  are  what  is  important:   –  A  login  screen  is  a  2   –  A  search  fetaure  is  an  8   •  Points  are  unit  less   As a user, I want to be able to have some but not all items in my cart gift wrapped. 5 Three  levels  of  planning...   Release plan Iteration plan Daily plan Daily plan Daily plan Daily plan Daily plan Iteration plan Daily plan 17  
  18. 18. 2013-­‐10-­‐24   ...three  levels  of  precision   Iteration Backlog Product Backlog Iteration 1 Iteration 2 As a frequent flyer I want to... 30 As a frequent flyer I want to... 50 As a frequent flyer I want to... 50 As a frequent flyer I want to... 20 As a frequent flyer I want to... Code the UI 8 Write test fixture 6 Code middle tier 12 Write tests 5 Automate tests 4 20 ”Yesterday I started on the UI; I should finish before the end of today.” ng Planni e Releas e Releas Plan 1 Sprint Sprint 2 3 Sprint Sprint 4-7 18  
  19. 19. 2013-­‐10-­‐24   Input   •  Product  Vision   •  Product  Backlog   •  Release  Goal   •  Velocity   Results   •  Release  Plan  ...   •  ...  and  even  more  important:   –  Learning   –  Understanding   –  Transparency  of  risks   19  
  20. 20. 2013-­‐10-­‐24   UpdaHng  the  release  plan   •  Revisit  the  release  plan  at  the  end  of  every   Sprint   •  Update  it  based  on:   –  Current  understanding  of  velocity   –  Current  prioriHzaHon  of  the  product  backlog   •  This  should  be  a  very  short  and  sweet  process   e Releas ga lannin P 20  
  21. 21. 2013-­‐10-­‐24   1. Determines -  when a release is needed, -  what functionality it must contain, and -  acceptable level of quality and cost Business   2. Determines 4. -  Focuses on Business Value derived from the release -  how long it takes to build the release -  Creates preliminary estimates 3. -  Refines estimateds as priority increases -  Selects what to work on for each Sprint Development Product  backlog   This Sprint : well defined work that can be done in <30 days & produce executable product Probable next sprint : backlog next in priority, depends on results from prior Sprint Planned Release Future Releases During a Sprint, that Sprint’s backlog is fixed and can only be changed as a result of the work being performed in that Sprint. Backlog outside the current Sprint is always changing, evolving, and being reprioritized. 21  
  22. 22. 2013-­‐10-­‐24   Release  planning   Release planning meeting Release Plan Sprint 1 Sprint 2 Sprint 3 Sprint 4-7 43   An  example  with  velocity  =  14   Sprint 1 Sprint 3-7 Story A Story E Story I 1 8 5Story J Story E 8 8 Sprint 2 Story C 3 Story D 5 Story H Story K 5 13 Story B Story L Story B 5 1 1 Story M Story F 5 Story G 1 Story P 4 12 Story N Story Q 6 4 Story O Story R 1 8 44   22  
  23. 23. 2013-­‐10-­‐24   An  esHmaHon  unit   Story points • A measure of the relative size of the feature • Based on how much and how hard • All that matter is the relative size of numbers 45   Release  Planning   Purpose To answer questions such as: • How much will be done by June 30? • When can we ship with this set of features? • How many people or team should be on this project? Inputs • Velocity • The amount of work completed in a sprint • Prioritised product backlog 46   23  
  24. 24. 2013-­‐10-­‐24   Velocity   •  A  useful  long-­‐term  measure  of  the  amount  of  work   completed  per  sprint   •  Not  a  predicHon  of  exactly  how  much  work  will  be   completed  in  each  sprint   40 sured Velocity is mea its you use in the un oduct to estimate pr ems backlog it 30 20 10 0 1 2 3 4 5 6 7 8 9 Sprints 47   Look  at  velocity  in  a  few  ways   Velocity 40 Last Observation = 36 Mean (Last 8) = 33 30 Mean (Worst 3) = 28 20 10 0 1 2 3 4 5 6 7 8 9 Sprints 48   24  
  25. 25. 2013-­‐10-­‐24   Extrapolate  from  velocity   Will have At our slowest velocity we’ll finish here Might have At our long-term average we’ll finish here At current velocity we’ll finish here Won’t have 49   Fixed-­‐date  planning:   an  example   Desired release date 15 December Todays Date 10 June Number of sprints 6 (monthly) Realistiv velocity 15 Optimistic velocity 20 Will have 6x15 Might have 6x20 Won’t have 50   25  
  26. 26. 2013-­‐10-­‐24   Fixed-­‐scope  planning:   an  example   Total story points desired 120 Realistic velocity 15 Optimistic velocity 20 120÷20= 120÷15= 51   Ranges   NoHce  in  both  cases  we  had  a  range   Either  a  scope  range  for  a  fixed  date  project:   •  –  ”By  that  date  you’ll  have  all  of  these  features  and   some  of  these.”   Or  a  date  range  for  a  fixed-­‐scope  project:   •  –  ”It  will  take  us  between  6  and  8  iteraHons  to  deliver  all   of  those  features.”   26  
  27. 27. 2013-­‐10-­‐24   Summary   Σ   AcHon  plan   27  
  28. 28. 2013-­‐10-­‐24   InspiraHon  and  references   •  •  Henrik  Kniberg   Mike  Cohn   •  •  •  •  hcp://agileatlas.org/arHcles/item/release-­‐planning-­‐in-­‐scrum   hcp://www.mitchlacey.com/intro-­‐to-­‐agile/scrum/release-­‐planning-­‐grooming   hcp://innoluHon.com/resources/glossary/release-­‐planning   hcp://www.jamesshore.com/Agile-­‐Book/release_planning.html   •  EssenHal  Scrum:  A  PracHcal  Guide  to  the  Most  Popular  Agile  Process     (Kenneth  S.  Rubin)   hcp://amzn.com/0137043295       •  Agile  EsHmaHng  and  Planning   (Mike  Cohn)   hcp://Hnyurl.com/39memw   Thank  you!   Arne  Åhlander   arne.ahlander@aqqurite.se   www.aqqurite.se   www.twicer.com/ArneAhl   hcp://www.linkedin.com/in/arneahlander   28  

×