Sprint Planning

• initiates the Sprint laying out the work to be performed for the Sprint
• Characteristics
  • Participants: the entire Scrum Team, may also invite other people to attend to provide advice
  • Time-box: 8 hours or less for a 1-month Sprint. For shorter Sprints, usually shorter
• Structure
  • 1. Preparation
    • PO ensures that PB is ordered to maximize the value of the team
    • PO ensures that attendees are prepared to discuss the most important PBIs and how they map to the Product Goal
    • Ensure that PB has been refined to an appropriate level
  • 2. WHY why is this sprint valuable
    • The PO proposes how the product could increase its value and utility in the current Sprint (have a general idea of a valuable Sprint Goal: The options for negotiating a Sprint Goal should also have been considered during Refinement, and reflected in backlog ordering)
    • Scrum Team collaborates to define a Sprint Goal: why the Sprint is valuable to stakeholders
  • 3. WHAT Plan the value that will be delivered
    • Developers work with the PO to select items from the PB to include in the current Sprint
    • Selecting how many PBIs may be challenging, the more the Developers know about their past performance, upcoming capacity, and their DoD, the more confident in their Sprint forecasts
    • The selection of work should be cohesive, and not just a grouping of unrelated and disparate items
    • Despite items should be Ready for selection, Scrum Team may refine these during this process
    • As tasks they may also include:
      • time for preparation of Releases
      • time for preparation of the Sprint Review
      • bugs to repair
      • improvements from the Sprint Retrospective
  • 4. WHY Be sure to agree a Sprint Goal
    • The Sprint Goal must be finalized prior to the end of Sprint Planning
    • Focus on outcomes, not on features
      • gives more freedom to renegotiate scope
      • creates a commitment for the SB, common goal which helps collaboration, a purpose for motivation, help to focus, etc
  • 5. HOW plan how the work will be done
    • Developers plan the work necessary to create an Increment that meets the DoD for each selected PBI
    • The PO does not need to be present, however, should be available, even if only remotely, to answer questions, provide clarification
    • Often done by decomposing PBIs into smaller items (tasks) of 1 day or less
    • at the sole discretion of the Developers. No one tells how to turn PBIs into Increments of value
    • This can be done by identifying and ordering the technical tasks that are likely to be involved
    • Do not need to be fully completed, just the next 2 days of work is enough if the others have been decomposed in bigger units
• NOTE: If more than one release is expected during the Sprint, this should be agreed with the PO and accounted for in the Sprint Backlog
• By the end of the Sprint Planning, the Development Team should be able to:
  • explain to the PO and SM how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment
  • begin implementing that plan immediately
• Inputs: PV, PG, PB, Past Performance, Upcoming Capacity, Velocity, DoD, …
• Outputs: SB: The Sprint Goal, the PBIs selected for the Sprint, plus the plan for delivering them