Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scrum Summarized


Published on

This book will introduce readers to the Agile software development methodology - Scrum. It is written for anyone and everyone who wish to understand and adopt Scrum. In this book, I have used my experience and knowledge of Scrum to describe the key concepts to get readers started on using Scrum.

Published in: Technology, Business
  • Be the first to comment

Scrum Summarized

  1. 1.     If you like the contents of this e‐book, you may buy the printed book from:‐mehra‐scrum‐summarized
  2. 2. Scrum  SUMMARIZED              Sachin Mehra, PMP 
  3. 3.     
  4. 4.                       © Sachin Mehra  All rights reserved. No parts of this publication may be  reproduced, stored in a retrieval system, or transmitted, in any  form or by any means, electronic, mechanical, photocopying,  recording, or otherwise, without the prior permission of the  author. 
  5. 5.   
  6. 6.             To  My family, my forever love. 
  7. 7.        
  8. 8. Contents at a Glance    Preface ...............................................................................................x  About the Author  ........................................................................... xiii  . Introduction ...................................................................................... 1  Birth of “Scrum”................................................................................ 5  Scrum ................................................................................................ 9  Agile Manifesto ............................................................................... 11  Principles behind the Agile Manifesto ............................................ 13  Scrum Alliance ................................................................................ 15  Roles in Scrum (entities involved) .................................................. 17  Getting started ............................................................................... 23  Where to go from here ................................................................... 35  Recommended Readings ................................................................ 37  References ...................................................................................... 39   
  9. 9. Preface    Thank you a lot for reading my book! My sincere aim is to get  you  started  on  adopting  and  practicing  Scrum  as  soon  as  possible.    This  book  is  not  the  final  step  in  your  Scrum  education and journey, rather this may be your first one.   This  book  is  written  for  anyone  and  everyone  who  wish  to  understand  and  adopt  Scrum.  In  this  book,  I  have  used  my  experience  and  knowledge  of  Scrum  to  describe  the  key  concepts to get you started, where you go from here is upto  you to decide.   I  wrote  my  first  book  titled  “Project  Communication  Management  Summarized”  in  2008,  which  took  me  almost  one year to complete and publish it. While I was writing it, I  realized that the TOC of my book keeps changing. I never got  satisfied with the content either. Every time I started writing  the  content,  I  reviewed  whatever  I  had  done  the  last  time  and made a list of changes I needed to make before looking  at  the  To‐Do  list.  I  always  had  a  big  backlog  of  work  to  accomplish,  however  the  changes  kept  adding  on  to  my  To‐ Do list. By the time I completed the book, I had re‐written the  matter  of  that  book  several  times.  Now  you  can  imagine  what I would have done with the TOC.   I had started with a list of To‐Dos (a backlog of things to be  done  to  complete  and  publish  the  book).  Based  on  my  time 
  10. 10. availability, book’s needs and my priorities I created another  list of To‐Dos which was a slice out of the main list. I started  working on the list to complete the small task in hand, it was  always  easier  to  work  on  and  complete  the  small  task  in  hand.  I  changed  my  hat  as  per  needs  to  act  as  reviewer,  writer and author of the book. My wife acted as a reviewer of  the final chapters/sections at the end of each slice of work. I  added  suggested/required  changes  in  the  main  To‐Do  list,  which  I  prioritized  to  create  the  work  slice  (smaller  list  of  tasks To‐Do) with definitive schedules and then worked upon  the  work  slice.  At  the  end  of  each  day,  I  used  to  mark  the  achievements  (tasks  completed)  in  the  word  doc  I  used  as  work slice. In all, I completed my book by using 17 such slices  of work.  So  what  did  I  do  all  this  while?  I  used  Scrum  to  help  me  complete  and  publish  my  book.  Yes,  this  is  what  Scrum  is,  well almost.  Over  the  past  few  years,  I  have  come  across  many  people  who  believe  that  they  practice  Agile  methodologies  (primarily  Scrum  and  XP),  and  I  would  say  that  they  are  all  right in their own perspective.   I would like to express my gratitude to my present and past  employers, where I earned my knowledge and experience to  make this book possible.  Many people helped me  directly and indirectly to  make this  book  a  reality.  My  sincere  thanks  to  all  the  people  who 
  11. 11. contributed to my thoughts and knowledge, and inspired me  to write this book.   My  special  thanks  to  Anand  Rajan,  my  mentor,  for  his  guidance,  insight,  and  common  sense  to  project  management.   I’m happy to acknowledge that this book has profited greatly  from Vikas Hazrati’s experience and knowledge. I  thank him  for reviewing content of this book in his personal time.   Finally, many thanks to Divya, my wife, for inspiring me and  proofreading this book.  Any  comments  about  this  book,  or  any  inaccuracies  that  might  be  present  (which  are  entirely  my  responsibility),  can  be sent to me at       Sachin Mehra   
  12. 12. About the Author        Sachin  Mehra  is  a  veteran  engineering  manager  who  is  a  MBA  and  certified  Project  Management  Professional  (PMP).  In over 12 years of software development and management  experience,  Sachin  has  worked  for  small  start‐up  to  established innovative companies.   He  has  vast  experience  in  Program/Project  Management,  Consulting,  Business  Analysis,  Outsourcing  and  Off‐shoring,  Service  transition  and  Management,  Onsite  Coordination,  Sales Support, Enterprise Architecture, Application Designing  and Development, Testing, Integration, and Implementation.  Post working hours, Sachin enjoys watching movies, reading,  writing, and spending time with his family.      
  13. 13.     
  14. 14. Scrum Summarized – by Sachin Mehra  Introduction    The  traditional  way  of  software  development  which  most  organizations  use  is  called  “Waterfall  Model”.  There  are  many  variants  of  this  model,  however  some  common  characteristic  are  big  upfront  requirements,  comprehensive  documentation,  contract  negotiation,  process  oriented,  and  planning  everything  before  the  work  starts  (plan  the  work  and work the plan approach).  We  know  that  change  is  the  only  constant.  Unfortunately,  while  using  waterfall  model,  most  often,  the  best  product  ideas,  requirement  changes,  and  feedback  from  customer  come at the end of the development cycle during user testing  (or worst, after production release), when changes are most  difficult  and  most  expensive.  Don’t  get  me  wrong,  I  am  not  saying that waterfall model does not work, it does and does  very well when applied to the right kind of projects.   The  fact  is  software  project  development  is  not  very  predictable.  Failures  occur  and  they  hurt,  very  badly.  The  customer  relationships,  team  morel,  and  organizational  reputation get negatively impacted.   This  is  where  agile  methodologies  (like  Scrum)  come  to  the  rescue. Agile approaches assume things change, and they do  change very frequently.  1   
  15. 15. Scrum Summarized – by Sachin Mehra          If you tell people where to go, but not how to get there,  you’ll be amazed at the results.  –General George S. Patton  2   
  16. 16. Scrum Summarized – by Sachin Mehra    Agile  methodologies  (like  Scrum)  are  helpful  and  effective  when:  • Requirements  are  unclear  or  ever  changing  or  are  not completely known at the start  • Working with tight schedules for delivery  • Working with new or innovative technology  This  book  will  introduce  you  to  the  Agile  software  development methodology ‐ Scrum. Scrum is a good method  of  managing  software  development  projects  in  an  environment where requirements are likely to change quickly  or are not completely known at the start of the project.   The  following  chapters  will  introduce  you  to  Scrum  and  related  key  concepts.  They  will  enable  you  to  jump  start  using Scrum to be able to manage your projects better. You  will also be guided  to other resources on the web  and print  media to enrich your knowledge and broaden your horizon.     3   
  17. 17. Scrum Summarized – by Sachin Mehra  4   
  18. 18. Scrum Summarized – by Sachin Mehra    Birth of “Scrum”    Scrum gets its names from the world of the sport, rugby. It is  the  name  of  the  formal  conglomeration  of  forwards  who  bind together in specific positions to move forward towards  their goal.       Who coined this  term “Scrum”?      Let’s read on  to find out.     5   
  19. 19. Scrum Summarized – by Sachin Mehra      In  1986,  Hirotaka  Takeuchi  and  Ikujiro  Nonaka  described  a  new holistic approach which increases speed and flexibility in  commercial  new  product  development.  They  compare  this  new  holistic  approach,  in  which  the  phases  strongly  overlap  and the whole process is performed by one cross‐functional  team across the different phases, to rugby, where the whole  team  quot;tries  to  go  to  the  distance  as  a  unit,  passing  the  ball  back and forthquot;.   In  1991,  DeGrace  and  Stahl,  in  Wicked  Problems,  Righteous  Solutions  referred  to  this  approach  as  Scrum,  a  rugby  term  mentioned in the article by Takeuchi and Nonaka.   In 1990s, Ken Schwaber used an approach that led to Scrum  at his company, Advanced Development Methods.     6   
  20. 20. Scrum Summarized – by Sachin Mehra  At  the  same  time,  Jeff  Sutherland  developed  a  similar  approach  at  Easel  Corporation  and  was  the  first  to  call  it  “Scrum”.   In 1995, Sutherland and Schwaber jointly presented a paper  describing  Scrum  at  OOPSLA  '95  in  Austin,  its  first  public  appearance.  Schwaber  and  Sutherland  collaborated  during  the  following  years  to  merge  the  above  writings,  their  experiences,  and  industry  best  practices  into  what  is  now  known  as  Scrum.  In  2001  Schwaber  teamed  up  with  Mike  Beedle  to  write  up  the  method  in  the  book  quot;Agile  Software  Development with SCRUMquot;.  Scrum is not an acronym, however the title of Schwaber and  Mike’s book confused many people, and still does.    So, SCRUM = Scrum? Right. 7   
  21. 21. Scrum Summarized – by Sachin Mehra    8   
  22. 22. Scrum Summarized – by Sachin Mehra    Scrum    Scrum  is  an  iterative  incremental  process  of  software  development.    Is that it?     Need a detailed    definition, read on.        As  per  Scrum  Alliance  website,  Scrum  is  a  lean  approach  to  software  development.  Scrum  is  an  agile  software  development  framework.  Work  is  structured  in  cycles  of  work called sprints, iterations of work  that are typically two  to  four  weeks  in  duration.  During  each  sprint,  teams  pull  from  a  prioritized  list  of  customer  requirements,  called  user  stories,  so  that  the  features  that  are  developed  first  are  of  9   
  23. 23. Scrum Summarized – by Sachin Mehra  the highest value to the customer. At the end of each sprint,  a potentially shippable product is delivered.      As per Control Chaos website, Scrum is a variation on Sashimi,  an  quot;all‐at‐oncequot;  approach  to  software  engineering.  Both  Scrum  and  Sashimi  are  suited  best  to  new  product  development  rather  than  extended  development.  Sashimi  originated with the Japanese and their experiences with the  Waterfall  model.  They  had  the  same  problems  with  the  Waterfall model as everybody else, so they adapted it to suit  their  own  style.  Realizing  that  speed  and  flexibility  are  as  important  as  high  quality  and  low  cost  they  reduced  the  number of phases to four ‐‐ requirements, design, prototype,  and  acceptance  ‐‐  without  removing  any  activities,  which  resulted in overlap of the Waterfall phases. Then they made  the  four  phases  overlap.  (Sashimi  is  a  way  of  presenting  sliced  raw  fish  where  each  slice  rests  partially  on  the  slice  before  it).  Other  companies  took  Sashimi  one  step  further,  reducing the phases to one and calling it Scrum. (A scrum is a  team pack in Rugby, everybody in the pack acts together with  everyone else to move the ball down the field).   Scrum is based on Agile  methodology. Let’s find out what  is Agile manifesto. 10   
  24. 24. Scrum Summarized – by Sachin Mehra    Agile Manifesto    As  per,  on  February  11‐13,  2001,  at  The  Lodge  at  Snowbird  ski  resort  in  the  Wasatch  mountains  of  Utah, seventeen people met to talk, ski, relax, and try to find  common  ground  and  of  course,  to  eat.  What  emerged  was  the Agile Software Development Manifesto.   Manifesto states:  • Individuals and interactions over processes and tools  • Working  software  over  comprehensive  documentation  • Customer collaboration over contract negotiation  • Responding to change over following a plan    That  is,  while  there  is  value  in  the  items  on  the  right,  we  value the items on the left more.    11   
  25. 25. Scrum Summarized – by Sachin Mehra    12   
  26. 26. Scrum Summarized – by Sachin Mehra  Principles behind the Agile Manifesto    As  per,  principles  behind  the  Agile  Manifesto are:  1. Our  highest  priority  is  to  satisfy  the  customer  through  early  and  continuous  delivery  of  valuable  software.  2. Welcome  changing  requirements,  even  late  in  development. Agile processes harness change for the  customer's competitive advantage.  3. Deliver  working  software  frequently,  from  a  couple  of weeks to a couple of months, with a preference to  the shorter timescale.  4. Business people and developers must work together  daily throughout the project.  5. Build  projects  around  motivated  individuals.  Give  them  the  environment  and  support  they  need,  and  trust them to get the job done.  6. The most efficient and effective method of conveying  information  to  and  within  a  development  team  is  face‐to‐face conversation.  13   
  27. 27. Scrum Summarized – by Sachin Mehra  7. Working  software  is  the  primary  measure  of  progress.   8. Agile processes promote sustainable development.  9. The  sponsors,  developers,  and  users  should  be  able  to maintain a constant pace indefinitely.  10. Continuous  attention  to  technical  excellence  and  good design enhances agility.  11. Simplicity‐‐the art of maximizing the amount of work  not done‐‐is essential.  12. The  best  architectures,  requirements,  and  designs  emerge from self‐organizing teams.  13. At  regular  intervals,  the  team  reflects  on  how  to  become  more  effective,  then  tunes  and  adjusts  its  behavior accordingly.     What is the relation  between Agile principles    and Scrum?   Scrum is a management    methodology for  implementing agile principles.   14   
  28. 28. Scrum Summarized – by Sachin Mehra    Scrum Alliance    The Scrum Alliance is a nonprofit organization committed to  delivering  articles,  resources,  courses,  and  events  that  will  help Scrum users be successful.   Founded by Ken Schwaber, Mike Cohn, and Esther Derby, the  Scrum  Alliance's  mission  is  to  promote  increased  awareness  and understanding of Scrum, provide resources to individuals  and  organizations  using  Scrum,  and  support  the  iterative  improvement of the software development profession.      Visit to  learn more about Scrum Alliance.  15   
  29. 29. Scrum Summarized – by Sachin Mehra    16   
  30. 30. Scrum Summarized – by Sachin Mehra    Roles in Scrum (entities involved)    Roles in Scrum are divided into two group, pigs and chickens,  based on a joke about a pig and a chicken in the book Agile  Project Management with Scrum that goes like:   A  pig  and  a  chicken  are  walking  down  a  road.  The  chicken  looks  at  the  pig  and  says,  quot;Hey,  why  don't  we  open  a  restaurant?quot;  The  pig  looks  back  at  the  chicken  and  says,  quot;Good idea, what do you want to call it?quot; The chicken thinks  about it and says, quot;Why don't we call it 'Ham and Eggs'?quot; quot;I  don't think so,quot; says the pig, quot;I'd be committed but you'd only  be involved.quot;  So the division of roles is based on the commitment level of  the parties involved in project.   Pigs are committed –   Team,  Product  Owner,  and  ScrumMaster  Everyone  else  is  a  chicken  –  Stakeholders,  Users,  and  Managers    17   
  31. 31. Scrum Summarized – by Sachin Mehra  Let’s look into    details of each role.              Team  –  Is  the  team  of  people  with  cross‐ functional  skills  (analysis,  architecting,  designing,  coding,  testing,  etc)  who  does  the  actual  work  of  creating  the  required  deliverables  (potentially  shippable  product).  Scrum  team  is  self‐organizing  team,  it  takes  its  own  decisions.  For  example,  they’ll  give  commitment  for  the  work  that  can  be  delivered and decide how to accomplish the commitments.   Primary  responsibility  of  the  team  is  to  build  potentially  shippable  product  at  the  end  of  every  sprint.  They  may  contribute their inputs and ideas to the product owner about  how to make the product better and more useful.  It is suggested to have a team size of 5‐7 people. In case of a  large  product,  product  should  be  divided  into  small  logical  parts, each of the part may have its own team.  18   
  32. 32. Scrum Summarized – by Sachin Mehra     Product Owner – Is the customer representative  or  internal  team  member  who  acts  as  the  voice  of  the  customer  and  bridge  the  gap  between  Scrum  team  and  the  customer.  They  ensure  that  the  team  is  able  to  understand  the user stories (requirements) and have all the information  required to create the product from a business perspective.     Primarily responsible for:  • Writing user stories  • Adding user stories to the product backlog  • Prioritizing the stories for next sprint  • Reviewing (along with others) the product at the end  of each sprint    Usually,  there  is  only  one  product  owner.  In  case  of  a  large  product,  product  should  be  divided  into  small  logical  parts,  each of the part may have its own product owner.    19   
  33. 33. Scrum Summarized – by Sachin Mehra   ScrumMaster – Is a facilitator for the team. He is  not  a  manager  or  leader  of  the  team  (Scrum  team  is  self‐ organizing),  hence  this  role  may  be  performed  by  a  team  member who may be 50% developer.    Primarily responsible for:  • Protecting  the  team  from  outside  interference  (like  change in scope of the sprint in progress)  • Ensuring that everyone understands and follows the  Scrum practices  • Conducting daily Scrum with the team   • Removes impediments to the ability of the team  • Conducting  sprint  retrospective  meeting  with  the  team at the end of the sprint    Usually, there is only one ScrumMaster per team.       20   
  34. 34. Scrum Summarized – by Sachin Mehra     Stakeholder – Is anyone who has an interest in  the  project.  It  may  be  an  individual  or  organization  that  are  actively  involved  in  the  project,  or  whose  interests  may  be  affected  as  a  result  of  project  execution  or  project  completion.  Primary  responsibility  of  the  stakeholders  is  to  review  the  sprint output and provide feedback.     User – Is someone who  will be  the end‐user of  the software product that is being created.      Manager  –  Is  someone  who  will  set  up  the  environment for the product development organization.  21   
  35. 35. Scrum Summarized – by Sachin Mehra        The secret of getting ahead is getting started. The secret of  getting started is breaking your complex overwhelming tasks  into small manageable tasks, and then starting on the first  one.  ‐Mark Twain      22   
  36. 36. Scrum Summarized – by Sachin Mehra  Getting started    Create a Product Backlog – Product owner creates a list of all  the  things  that  can  be  done  by  the  team  to  create  the  product,  it  is  called  Product  Backlog.  It  may  include  the  required  new  functionality,  modification  in  existing  functionality  or  bugs/issues  in  the  functionality  with  broad  descriptions of each item.    Customers, User, etc provide requirements to product owner      Product owner creates the product backlog  23   
  37. 37. Scrum Summarized – by Sachin Mehra    #  Description  Rough  Estimate  1  Manage user   16  2  Send email on user creation  4  3  Manage store items   12  4  Search sales records  4  Sample Product Backlog  Product  backlog  is  continuously  updated  by  the  product  owner to reflect the change in the need/choice/feedback/etc  of the customers.  Prioritize the product backlog – Product owner is responsible  for  creating  and  maintaining  this  backlog.  Product  owner  prioritizes  the  list  in  the  order  of  value  delivered  to  the  customer. End result is highest value items at the top of the  list.    24   
  38. 38. Scrum Summarized – by Sachin Mehra      Alright, now that we have  the prioritized list of    items, what’s next?     Product owner will freeze the    top items so that we start  sprint planning.           Sprint Planning – First step to start a sprint is to have a sprint  planning meeting. ScrumMaster facilitate a meeting between  Product  owner  and  team  to  discuss  the  goals  and  status  of  the product backlog.   First step in the planning is to find out the total time that can  be used for the sprint. This time excludes time spent on work  breaks (lunch, coffee, etc) or time spent in meetings or doing  other organizational activities (if any).    25   
  39. 39. Scrum Summarized – by Sachin Mehra  For example:   • Each of my team member has 6hrs a day that can be  used for the sprint  • We are a 5 people team  • Our sprint is of 5 working days   Hence, I have total of (6 x 5 x 5) 150 sprint hours. This allows  us to accomplish 150hrs of work from the product backlog.    Second  step  is  to  start  with  the  product  backlog  top  items  (high  priority  and  value  items)  one‐by‐one  and  break  them  into smaller tasks. Any clarification required is discussed with  the product owner.  Items  are  broken  down  into  hours  with  no  task  being  more  than 16hrs. In case the task is longer than 16hrs, it is further  divided into smaller tasks until it is below 16hrs.  Team  provides  estimates  and  decides  how  much  work  they  will  commit  to  complete.  Nobody  assigns  the  task,  team  chooses it themselves.   This  process  of  taking  items  from  product  backlog  is  continued till all available sprint hours are consumed.    26   
  40. 40. Scrum Summarized – by Sachin Mehra  High priority and Break into smaller tasks high value items Sprint backlog Product backlog – functionality which is top items committed to be deliver   At  the  end  of  the  sprint  planning  meeting,  team  will  have  a  list  of  tasks  (with  details)  which  they  own  and  have  committed to deliver. This document is called Sprint backlog.   Only measurable/verifiable goals, which have to be attained  at the end of the sprint, are committed.    Sprint length: 1 week  Working days during the sprint: 5  #  Task  M  T  W  T  F  8  Setup new store  8  16 8  8  0  28  Create CSS  0  12 16  16  8  21  Add standard error codes  16  4  16  8  8  Sample Sprint Backlog    27   
  41. 41. Scrum Summarized – by Sachin Mehra  Sprint – Once the sprint planning meeting is over (should be  one  day  long),  the  sprint  starts.  Sprint  is  a  period  of  time  when  the  team  works  on  the  sprint  backlog  to  complete  what they have committed. Sprint is usually 2‐4 weeks long,  30 days if we go by the book.  ScrumMaster  ensures  that  there  is  no  additional  request  added  to  the  sprint  backlog  during  the  sprint  and  team  is  able to focus on delivering what they committed.  Scrum team working one team room   Daily  Scrum  (standup  meeting)  –  This  is  a  team  meeting  which  happens  at  scheduled  place  every  day  at  same  time.  Anyone  can  attend  this  meeting,  however  only  team  is  allowed to speak. Duration of this meeting is 15 minutes (or  less) and everybody has to stand (that’s why it is also called a  standup meeting).     28   
  42. 42. Scrum Summarized – by Sachin Mehra  Team talks about three things:  1. Progress made since last meeting.  2. Tasks planned to be performed today.  3. Anything  that  prevents  a  team  member  from  performing  work  as  efficiently  as  possible  (this  is  called Impediment is Scrum).  Only reporting happens during this meeting, no discussion is  held.  ScrumMaster  takes  notes  on  impediments  during  the  meeting  and  works  towards  removing  them  after  the  meeting,  he  may  setup  separate  meetings  to  resolve  impediments that cannot be resolved during the meeting.    ScrumMaster discusses with stakeholder to resolves team impediments     ScrumMaster  maintains  the  sprint  backlog  by  updating  task  status  to  reflect  the  latest  status.  It  reflects  the  status  of  tasks  (is  it  done  or  not;  if  not  done,  how  much  time  will  it  take to complete). This helps the team understand the total  29   
  43. 43. Scrum Summarized – by Sachin Mehra  amount  of  time  (efforts)  required  to  complete  their  committed work.   ScrumMaster  plots  this  (decreasing)  effort  on  the  graph  to  shows the progress made each day by the team. This chart is  called a sprint Burndown chart.      Burndown chart    Sprint review meeting – Once the sprint is over, team gives a  demo  of  the  functioning  software  (potentially  shippable  product) of the sprit to product owner, users, managers and  everyone else who has his interest vested in the product.   30   
  44. 44. Scrum Summarized – by Sachin Mehra  Reviewers  can  share  their  feedback  and  inputs  during  this  meeting, this feedback can be used for next sprint.     Retrospective meeting – It is a meeting of the team, product  owner and ScrumMaster which is held after the sprint review  meeting  to  understand  what  works  (and  what  doesn’t).  It  helps  identify  the  areas  of  improvements  for  each  of  the  party in subsequent sprints.  During this  meeting, common issues are further analyzed to  pin‐point  the  root  cause  and  eliminate  the  issue  in  subsequent sprints. The resultant actions (and their results in  next  sprint)  can  be  reviewed  during  the  next  retrospective  meeting.  How many sprints should    we do to release the  product?     Do as many sprints as you need    to complete what product owner  think is required to release the    product.     31   
  45. 45. Scrum Summarized – by Sachin Mehra      Release – After a few sprints, product owner takes a decision  to  release  the  product  to  the  users  when  he  thinks  the  product is complete, this is called a release.       Product release may be time or functionality driven. Market  conditions  may  also  affect  the  release.  In  case  of  large  products,  release  meeting  may  be  part  of  the  first  (or  all)  sprint  planning  meetings  to  create  a  high  level  plan  for  the  product release.   32   
  46. 46. Scrum Summarized – by Sachin Mehra  Time to ship the product to the end users     At this point, another sprint may be required to do the final  integration and testing in preparation for the launch.      I got it all! Now, I can do    Scrum.   33   
  47. 47. Scrum Summarized – by Sachin Mehra            I have missed more than 9,000 shots in my career.   I have lost almost 300 games.   On 26 occasions I have been entrusted to take the game  winning shot, and I missed.   And I have failed over and over and over again in my life.   And that is precisely why I succeed.    ‐ Michael Jordan  34   
  48. 48. Scrum Summarized – by Sachin Mehra    Where to go from here    In the preface of this book I had mentioned that you’ll have  to decide where you go from here. Again, this book is not the  final  step  of  your  Scrum  journey,  rather  it  may  be  your  first  one.   There  is  no  journey  without  initial  problems.  Your  Scrum  journey is not going to be any different. You may face issues  and there will be times when you’ll feel that Scrum does not  work,  my  only  suggestion  is,  don’t  give‐up.  Adapt  your  processes to match your needs.  I  suggest,  you  continue  your  journey  at  the  recommended  readings  section  of  this  book  and  seriously  consider  taking  Scrum training/coaching.      All the best! Hope you  have a pleasant Scrum  journey.  35   
  49. 49. Scrum Summarized – by Sachin Mehra     36   
  50. 50. Scrum Summarized – by Sachin Mehra    Recommended Readings            1. Agile Software Development with SCRUM ‐ by Ken  Schwaber and Mike Beedle (Buy at Amazon ‐‐Software‐Development‐ Scrum/dp/0130676349)  2. Agile and Iterative Development: A Manager's Guide ‐ By  Craig Larman (Buy at Amazon ‐‐Iterative‐Development‐ Managers‐Software/dp/0131111558/ref=pd_sim_b_4)  3. Agile Software Development ‐ by Alistair Cockburn  4. Reference material at   5. Reference material at  6. Agile estimating and planning – by Robert C Martin  37   
  51. 51. Scrum Summarized – by Sachin Mehra                38   
  52. 52. Scrum Summarized – by Sachin Mehra  References        1.  2.  3.  4.  5. Agile Software Development with SCRUM ‐ by Ken  Schwaber and Mike Beedle                 39   
  53. 53. Scrum Summarized – by Sachin Mehra    40