“I adore spontaneity, providing it is carefully planned.” Welcome to Sprint Planning.
Your Sprint Backlog serves as your plan for a single Sprint. When we say plan, the phrase should be used loosely. In the beginning, imagine a nice pretty map with directions, but by the time you’ve reached your destination, it’s wrinkled with a bunch of scribbles all over and multiple routes have been followed.
Whether you’re overcoming speed bumps with stakeholders, or you’re switching seats to support one of your teammates, it’s all but inevitable that you’ll have to take the “scenic route” on a couple of occasions.
Don’t worry, you won’t be there forever.
We know the dread of walking into a planning meeting. The tiny bit of hope you cling to that maybe, just maybe, it’ll end early. Then Kevin walks in and your dreams are crushed because he often digresses about things that have zero to do with the subject at hand. We all have a Kevin.
That’s what makes Sprint Planning meetings so efficient. It’s time-boxed so that you waste little time. Time-boxing constrains the duration of a meeting to an upper maximum limit. It’s also important to note that meetings can be even shorter than planned— trimming waste is a fundamental principle of the framework. Scrum Master’s are really good at ensuring meetings do not exceed their time-boxes as it’s one of their primary responsibilities.
The Sprint itself is time-boxed. The Scrum guide limits them to a maximum of one month but in practice, they are commonly 2 weeks. According to the Scrum Guide, Sprint planning is limited to 8 hours in a one-month Sprint and usually shorter with shorter Sprints. For a Sprint length of two weeks, you’re generally going to limit the meeting to 4 hours. Almost every modern product development technique leverages time boxing, beginning with early efforts at DuPont back in the ’80s (where productivity tripled after adoption)! Through decades of refinement and improvement, thousands of organizations have successfully implemented time boxing, helping them consolidate project scope, reduce budgets, and accelerate the delivery of value.
Get some answers.
Your Sprint Planning meeting will set the tone for the remainder of the development cycle, so it’s important to have a good sense of what questions should be asked (and what kind of answers you’re looking for). Here’s a few examples of questions that could help drive higher productivity during the discussion:
- What risks will we face during this sprint, and what are we doing to mitigate them?
- Are we optimizing for speed? Quality? Growth? Or something else?
- Who are we depending on outside of the team during this Sprint?
- Does everyone on the team share the same understanding of our “Definition of Done?”
- What can be delivered in this increment? How can this work best be achieved?
- What is the purpose of this work and how will we summarize that into a Sprint Goal?
By keeping your line of questioning clear yet comprehensive, your team will more effectively adjust to the context and conditions of the upcoming Sprint, remaining aligned and focused even when challenges do occur.
Keep in mind that the outcome of this meeting shouldn’t just be small talk and warm, fuzzy feelings. This discussion needs to produce actionable directives that can be incorporated into your Sprint Backlog, which will serve as the basis for your team’s direction going forward.
The Sprint backlog gets the love.
Although conversations during your Sprint Planning meeting can certainly inform the contents of your Product Backlog, the Sprint Backlog is the event’s primary beneficiary. Based on the priorities highlighted by your team during Sprint Planning, specific Product Backlog Items are selected from the Product Backlog to be moved into the Sprint Backlog.
The Sprint Backlog will serve as a tentative “to-do list” for the weeks that follow, giving the team concrete items to execute on that line up with their Sprint Goal. Of course, like most things in Scrum, work here is not a commitment, but a forecast. Scrum is predicated on the ability to respond to uncertainty, so there’s no explicit obligation to stick to the work selected but there is an expectation that your Sprint Goal will be achieved.
So… Where are we going?
This is why the Sprint Goal is important. It’s pretty hard to make planning decisions if you have no idea where you’re headed. A goal gives your team a purpose that will guide dozens of decisions down the line. Eventually, your developers will be forced to make trade-offs, but this can be difficult to do if you don’t know what you’re optimizing for. A Sprint Goal not only gives your team a clear-cut target to work towards— but you also allow them the flexibility to make their own decisions on how to best achieve it.
The importance of having a Sprint Goal cannot be understated. To give you some context, the term “Scrum Master” only pops up 11 times in the 2020 Scrum Guide, whereas “Sprint Goal” appears in 19. Imagine a huddle in a football game. You think they are talking about where they will pick up dinner later? Or is the conversation geared toward how to get a first down, how to score, how to win? These mutual goals make all the difference.
Want a tour guide?
Collaboration, time boxing, and a long-term perspective are critical components in a Sprint Planning meeting- a crucial component for setting the tone throughout the entire development cycle. Sprint Planning gives contributors the opportunity to ask critical questions and organize their priorities. In navigating the finer points of Sprint Planning, however, it’s easy to get lost. That’s why it’s important to have someone there to guide you through the process— someone who has experience in traversing these challenges across a diversity of organizations. Someone like Responsive Advisors.
With years of Scrum experience and a track record of remarkable business successes, Responsive Advisors has a bias towards action that’s contagious. They can help you quickly take charge of organizational transformation, leading your team through the opportunities and challenges your turn towards Scrum will inevitably present.
The most important thing? Getting started. As the empirical process unfolds, the benefits of these new ways of working will empower your team in every respect.
