Getting Started with Product Delivery

Sprint Planning & Sprint Backlog (Part 7 of 10)

If the plan doesn’t work, change the plan, not the goal

Vincent Carter

Published in

Straight Scrum

7 min readAug 8, 2021

The most iconic scene in the movie Saving Private Ryan is the opening D-Day sequence of the U.S landing on Omaha Beach. In a nutshell, this scene is a perfect example of a plan that literally blows up in your face and everything goes to hell. However, the troops were able to adapt to the disorganization of no longer having a plan that works. Enough soldiers were able to struggle up onto the bluffs, and by nightfall, the American and British forces had conquered a small area of Nazi-occupied France. How did they pull it off? They had a GOAL. The primary goal was to secure the beachhead 5 miles deep which would allow them to link with the British landings at Gold Beach. Having a goal allowed for everything that could possibly go wrong to go wrong and still keep the troops focused on an outcome.

If we were to take this real-life scenario and put it into terms of Product Delivery using Scrum, you would have a Product Vision that was “to defeat the Axis powers and create a peaceful post-war world.” You would also have a Product Goal which was “to liberate France” and then there would be the Sprint Goal which was “to secure the beachhead 5 miles deep.”

In Scrum, the whole point of a Sprint is that when you find yourself in a complex situation, similar to the one with which the allied generals were faced, where there are no right answers and you have no idea what will work, you just have to try something. That’s your Sprint Goal. You have to set a Sprint Goal which will allow you to try something so you can quickly get feedback to determine if you are heading in the right direction. If you are getting positive results, you do more of that and if things aren’t working well, stop doing that. Hopefully, you have a Product Vision and a Product Goal, and now is the time to start trying things out. Those things are your Sprint Goal and you create your Sprint Goal during Sprint Planning.

Sprint Planning

The first event at the beginning of every Sprint is Sprint Planning and there are three topics that are covered during this event. They are the Why, the What, and the How.

Sprint Planning — Topic One (Why): Why is this Sprint Valuable?

When you start Sprint Planning, determining the “WHY” is the first thing you should do with your Scrum Team. The Scrum Team needs to ask and answer, “Why is this Sprint important?” What is that one focusing goal, that no matter what will allow the team to have a compass in an environment with so many uncertainties? That one focusing goal for the Sprint is called the Sprint Goal.

The Product Owner should come to the Sprint Planning event with an objective in mind that would help increase the value of the product and move everyone closer to the Product Goal. However, it is the entire Scrum Team that collaborates to develop a Sprint Goal. It’s important that the Scrum Team is involved in the creation of the Sprint Goal in order to provide a shared high-level objective that the entire team is committed to achieving for that Sprint. The Sprint Goal guides the Developers on why they are building the current Increment. The output of this topic is the Sprint Goal.

Sprint Planning — Topic Two (What): What can be done this Sprint?

Now that the Scrum Team has come to an agreement as to “Why” they are building the current increment, the next step or topic is to determine the “What.” What are the items that the Developers, through discussion with the Product Owner, will pull from the Product Backlog that will help them to achieve the Sprint Goal? Per the Scrum Guide, these Product Backlog Items should be items that the Scrum Team believes can be completed, meet their Definition of Done, within one Sprint. If not, then this is a great place to do some additional refinement outside of the activity of Product Backlog Refinement. The Scrum Team may refine these items during this process, which increases understanding and confidence. Selecting how much can be completed within a Sprint may be challenging. However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in determining how many items they can pull. The output of this topic is the set of items that were pulled for the Sprint.

Sprint Planning — Topic Three (How): How will the chosen work get done?

This is where the Developers create a plan for how they will build an Increment that meets the Definition of Done. It’s also the topic that I have noticed a lot of teams not utilizing well or even at all. For each and every item that was selected into the Sprint, the Developers need to plan how they will turn it into a usable Increment. This is where even more refinement can occur and the items are usually decomposed into smaller pieces of executable tasks of one day or less. The Developers also discuss who needs to execute these tasks and in what sequence. The output of this topic is a ‘game plan’ that makes clear how the Developers will work together to meet the Sprint Goal and deliver a potentially shippable Increment.

Timeboxed

It’s important to note that Sprint Planning is an “event” and all events are timeboxed, meaning that there is a maximum length of time for a specific activity. For Sprint Planning the maximum length of time is eight hours for a one-month Sprint. The Scrum Team will have to use inspection and adaptation to determine the right amount of time as long as it doesn’t exceed the timebox of eight hours.

Artifact: Sprint Backlog

When Sprint Planning has been completed the overall outcome is an Artifact called the Sprint Backlog. This is also an area where a lot of people get confused. The Sprint Backlog is not just the set of Product Backlog Items that were pulled into the Sprint. When I ask teams to see their Sprint Backlog, they usually only show me a Jira board that is filtered on the Items that were pulled into Sprint. The problem is that this is only 1/3 of what defines a Sprint Backlog. The Sprint Backlog is the combination of the output from each of the topics. Topic 1 is the Spring Goal, Topic 2 is the set of Items pulled for the Sprint, and Topic 3 is the plan. All three of these (the Why, the What, and the How) make up the definition of a Sprint Backlog.

Final Thoughts

Sprint Planning is the time for the Developers and the Product Owner to negotiate. The Product Owner can help to clarify the selected Product Backlog Items and make trade-offs. If the Developers determine that they have too much or too little work, they may renegotiate the selected Product Backlog Items with the Product Owner. Scrum is built on the shoulders of Empiricism and each Event provides a formal opportunity to inspect and adapt Scrum Artifacts. For Sprint Planning, the entire Scrum Team uses this event to “Inspect” the Product Backlog Items based on the Sprint Goal and “Adapt” the Sprint Backlog by determining which Product Backlog Items to pull.