Essence of Scrum: Sprint Planning

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. ↩︎

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. ↩︎

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 2020 version says that “the Sprint Goal also creates coherence and focus, encouraging the Scrum 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.” ↩︎

The Scrum Guide 2017 puts more emphasis on the follow-up actions for Sprint Retrospective : “To ensure continuous improvement, it (the Sprint Backlog) includes at least one high priority way in which the team works, identified in the previous Retrospective meeting” (p.16).    In 2020 version it is expressed in a more relaxed tone: “The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.”    Emerson Mills suggested in his CSM class putting these identified technical improvements into Sprint Planning Part 2 (source: “我在第二次 Certified ScrumMaster 課程學到的事（1）”. ↩︎

The Scrum Guide 2017 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. ↩︎

Definition of Ready ↩︎

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.” ↩︎

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.” ↩︎

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

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

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." ↩︎

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. ↩︎

Enabling specification ↩︎