… now that a Product Backlog has been defined and refined, the PBIs are still only potential value. They produce value (i.e., move to the end of the Value Stream) only when they are made real through development. You are ready to embark on a Sprint to develop one or more PBIs to create a Potentially Shippable Product Increment.
✥ ✥ ✥
A Sprint should produce a Potentially Shippable Product Increment. Yet simply pulling PBIs off the top of the Product Backlog does not necessarily result in work that creates the Greatest Value or work that fits into the Sprint’s time box to produce the product increment.
It would be nice to just work from the top of the Product Backlog without thinking about it, but there are several reasons that it doesn’t work. Product Backlog Items (PBIs) are not of uniform size and the team has to create a deliverable product increment within the time box of a Sprint. So the team has to figure out what will fit and they may have to juggle the PBI ordering, and maybe even adjust some PBI content.
The team typically does not understand PBIs in enough detail to completely prescribe how they will be developed. In fact, design of PBIs to that level is waste because PBIs might queue up undeveloped for some time, and the business and team context may change over time making all the work you have put into the PBIs irrelevant. Or other PBIs may come up, possibly deferring a PBI indefinitely. But some design thinking is in order to understand how a given PBI will be developed and you need to do this at the right time.
Development Team members may need to adjust their work plan during the Sprint based on increased understanding of business needs and technical constraints. This is difficult when working with large, monolithic PBIs.
At the beginning of every Sprint the Scrum Team (or all the teams that together deliver a jointly developed product increment) meets to plan how they will create value during the Sprint. This involves developing a Sprint Goal and creating a plan for what will be developed and how it will be developed. This requires that the Scrum Team perform sufficient design on the upcoming work to have a high degree of confidence about what the upcoming development entails, and that it can be completed during the Sprint (see Granularity Gradient).
During Sprint Planning the Scrum Team creates the Sprint Goal and produces the initial version of the Sprint Backlog. An incidental output is an updated Product Backlog. If the Product Backlog is not yet a totally refined backlog at the beginning of Sprint Planning (perhaps because the Product Owner has added new items near the top of the backlog since last meeting with the Developers) then the Scrum Team discusses, estimates, breaks down and orders the new PBIs in preparation for their inclusion in the work plan of the imminent Sprint.
The main activities of Sprint Planning are for the team to ensure the Product Backlog is Ready; to come to a consensus on a Sprint Goal; to select the PBIs the team forecasts they can deliver this Sprint; and to plan how to do that work and achieve the Sprint Goal. Most teams find it best to do these activities concurrently, for example figuring out how to do work helps one understand its scope and effort required (velocity can be effective for forecasting the amount of work that can be done). That, of course, influences how much work can be done. Sprint Planning is a point at which the level of refinement of PBIs takes a big jump from the level in the Product Backlog.
It is important to allow sufficient time in the Sprint Planning for sufficient design to create a well-understood Sprint Backlog. But the planning should be time boxed. A rule of thumb is that the event should endure a maximum of 8 hours for a 4 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 planning and to correspondingly increase the time spent on building product.
If a PBI is not sufficiently specified for the team to design its associated Sprint Backlog Items, the Development Team should not accept it for the Sprint (see Enabling Specification or Definition of Ready). Inadequately specified PBIs are a major cause of effort bloat leading to Sprint failure. Jeff Sutherland reports on one Scrum Team that had a standing rule that if PBIs were not sufficiently specified, the team would all go to the beach. (This sent a clear message to the Product Owner about the Product Backlog!)
A key output of Sprint Planning is that the Development Team should be able to explain how it can accomplish the Sprint Goal. The ability to explain it comes through a thorough understanding of the work to be done, which raises the probability that the team actually can do it in the amount of time they estimate. A team might consider this as a measure of the effectiveness of the meeting.
As noted above, Sprint Planning produces the initial version of the Sprint Backlog. This is the initial plan the Development Team works from in the Sprint, and is refined and adjusted every day at the Daily Scrum. Thus the Daily Scrum can be considered as a daily re-planning meeting.
✥ ✥ ✥
The quality of Sprint Planning strongly influences the success of subsequent Daily Scrum events. If the Sprint Goal and Sprint Backlog are well defined and understood, the Development Team is likely to have effective Daily Scrums, and any required replanning will be clear. A poor Sprint Planning activity may increase the burden on recurring Scrum of Scrums doing multi-team development.
The obvious outputs of Sprint Planning are the Sprint Backlog and the Sprint Goal. But Sprint Planning also strengthens the Unity of Purpose, and helps the Development Team and the Product Owner better understand each other’s needs and motivations. This strengthens the Community of Trust, and cultivates Fertile Soil.
Picture from: PresenterMedia.com.