This article discusses the essence of Sprint Planning .

In a nutshell

Sprint Planning is a time-boxed1 event in which the Scrum Team defines the Sprint Goal and makes a feasible plan for the goal, to the best knowledge, information and belief of the team.

Output

Essential:

  • Sprint Goal
  • A feasible plan for achieving the Sprint Goal

  • Sprint Backlog Items with the property of INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable)2

Better:

  • A coherent Sprint Goal 3 and expectation for the outcome to be seen at Sprint Review

Input

Essential:

  • Strategy breakdown (e.g., product roadmap, OKR, OGSM, impact mapping, user story mapping).

  • A Product Backlog that has been refined during Product Backlog Refinement and adapted during previous Sprint Review

  • Action items created during previous Sprint Retrospective 4

  • Influences5

Better:

  • The top Product Backlog Items meet the Definition of Ready criteria6 defined and evolved by the Scrum Team .

Tools and Techniques

Essential:

  • Short-term strategic planning statements in brief

  • Judgment to balance a variety of needs and goals7, especially “whole product focus”8 and technical excellence9

  • Logical approach to ordering items

  • Logical approach to breaking down items

  • Estimation in proper granularity10

  • Encouraging a focus on the team rather than individuals.

Better:

  • Two parts planning11

  • SPIDR (Spike, Paths, Interfaces, Data, and Rules)12 (should be used in Product Backlog Refinement as well)

  • Techniques for enabling specification13 (should be used in Product Backlog Refinement as well)

  • Visualized information radiators (e.g., Scrum board, Kanban board).

  • Self-organizing instead of being conducted solely by Scrum Master .

  • Encouraging participative decision-making in proposal and ordering of Sprint Backlog Items

  

'Essence of Scrum' Series

Product Backlog Refinement

Daily Scrum

❸ Sprint Planning

Sprint Review


  1. The Scrum Guide says that “Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. […] The Scrum Master teaches the Scrum Team to keep it within the time-box." A Scrum Book suggests that “It is important that Sprint Planning allow time for enough design to create a well-understood Sprint Backlog. But the planning should be time-boxed. A rule of thumb is that the event should take no more than four hours for a two-week Sprint and proportionally less for shorter Sprints. If it takes longer, it takes longer—but seek kaizen opportunities to reduce the amount of time to plan and to correspondingly increase the time spent on building product." Teddy Chen advocates in his article sticking to the timebox to avoid the “big up-front design” symptom. ↩︎

  2. Agile Alliance says that “The acronym INVEST helps to remember a widely accepted set of criteria, or checklist, to assess the quality of a user story." Read Bob Hartman’s article “New to agile? INVEST in good user stories” for more info. ↩︎

  3. Scrum works better when it is considered an enabling engine toward a coherent goal rather than just a collection of work packages by chance. The Scrum Guide says that “the Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives." A Scrum Book says that “The Scrum Team can use the Sprint Goal to frame the selection of PBIs for the Sprint but in some sense the Sprint Goal is more important even than the sum of the individual PBIs." Roman Pichler says in his article “A Template for formulating great sprint goals” that “your sprint goal should differ from your user stories. The goal explains the why it is a good idea to carry out the sprint an implement the stories. The user stories enable you to reach the goal. It’s a common mistake to confuse the two." ↩︎

  4. The Scrum Guide 2017 puts more emphasis on the follow-up actions for Sprint Retrospective : “The Sprint Backlog […] To ensure continuous improvement, it includes at least one high priority way in which the team works, identified in the previous Retrospective meeting” (p.16). Emerson Mills suggested in his CSM class putting these identified technical improvements into Sprint Planning Part 2 (source: “我在第二次 Certified ScrumMaster 課程學到的事(1)”. ↩︎

  5. The Scrum Guide says that “Each Sprint may be considered a project with no more than a one-month horizon” (p.9). In this regard, a sprint cannot be immune from influences discussed in the PMBOK Guide, such as enterprise environmental factors and organizational process assets. ↩︎

  6. Definition of Ready ↩︎

  7. Peter Drucker emphasized in his book The Practice of Management (pp. 62-63, 87) that “To manage a business is to balance a variety of needs and goals. This requires judgment. The search for the one objective is essentially a search for a magic formula that will make judgment unnecessary. But the attempt to replace judgment by formula is always irrational; all that can be done is to make judgment possible by narrowing its range and the available alternatives, giving it clear focus, a sound foundation in facts and reliable measurements of the effects and validity of actions and decisions. And this, by the very nature of business enterprise, requires multiple objectives. […] Yet, there is no formula for doing the job. Each business requires its own balance—and it may require a different balance at different times." ↩︎

  8. The definition of “product” by the Scrum Team has also defined what is in scope and what is by default out of scope for the team. For example, what parts of Ops should be handled by the Scrum Team ? LeSS advocates a broader product definition and a “whole product focus” point of view: “Whenever there is a choice to optimize a team output or the whole product, we always chose the whole product. […] In many large product development groups, getting everyone to focus on the whole product instead of their individual parts/tasks/specialization is one of the hardest parts of scaling Scrum. Always keep a whole product focus, keep reminding everyone there is no value in separate parts or half-working parts." ↩︎

  9. Principles behind the Agile Manifesto” emphasizes that “Continuous attention to technical excellence and good design enhances agility.” LeSS identifies several areas of technical excellence. ↩︎

  10. Mike Cohn discusses different levels of estimation activities in his article “Why Agile Teams Should Estimate at Two Different Levels.” ↩︎

  11. It is common to divide the Sprint Planning into 2 parts. Here is a good quote from LeSS: "Sprint Planning One focuses on selection of ready items from those offered by the Product Owner, wrapping up lingering questions, and definition of the Sprint Goal. Sprint Planning Two focuses on creating a plan of work to get to ‘done’ for each item. The items and plan of action or tasks comprise the Sprint Backlog." ↩︎

  12. Mike Cohn proposed the SPIDR approach (spike, paths, interfaces, data, and rules) for breaking down user stories. Watch the “Stop Wasting Time Splitting Stories” video for more details. ↩︎

  13. Enabling specification ↩︎