Purpose

The purpose of this video is to provide you with a quick overview of Sprint Planning. We recommend showing this video to your team right before they do a Sprint Planning event.

Transcript

OK, it’s that time again.

Your previous sprint has ended and its time to take everything we learned during the Sprint Review and the Sprint Retrospective and plan our next move. It’s time for Sprint Planning!

Sprint Planning is done at the beginning of every Sprint and is the opportunity for the Scrum team to decide

  • What’s our capacity for the Sprint?
  • What is the goal for the Sprint?
  • Which Product Backlog Items will help us achieve the goal?
  • How do we, the Developers, plan to complete the Product Backlog Items?

Sprint Planning should take approximately 2 hours for every week of Sprint length. In other words, for a 2 week Sprint, you should expect to take around 3-4 hours to complete Sprint Planning.

For a one month Sprint, Sprint Planning should take a full day.

Before you start Sprint Planning, let’s talk about each of the activities that should be done during the event.

First, determine how much work can be loaded into the Sprint.

Don’t go overboard with this. Trying to add up everyone’s hours is a big waste of time. Just consider doing something simple: how much work did you get done in the previous Sprint? All things remaining equal, plan the same in this Sprint as you finished in the previous Sprint.

If there’s a holiday or vacation days during the Sprint, plan a little less. You can’t be precise and there’s really no point trying. Just make your best guess and get started.

Next, we need to determine the Sprint Goal.

The Sprint Goal acts as a theme for the Sprint and can be very powerful for the team. Also, it should be derived from the Product Goal. For example, if the Product Goal is to complete a number of features for the next product release, the Sprint Goal should start with what the team should accomplish this Sprint to move us closer to the Product Goal.

A well-written Sprint Goal keeps us focused on creating valuable outcomes instead of simply trying to finish Product Backlog Items.

For example, “Finish the registration capability for the customer.”

The power in a goal like this is that the team, working together, can change the content of the Sprint as needed to ensure that the registration capability is, in fact, finished by the end of the Sprint. Any other work becomes a lower priority. A Sprint Goal could also incorporate a learning objective for the team.

For example, “Get the entire team trained on the new forms generation tool.” With a goal like this, product backlog items can be added to the Sprint regardless of where they occur in the Product Backlog if they help the team achieve the goal of understanding the forms generation tool.

You may also want to incorporate what you learned in your Sprint Retrospective into the Sprint Goal. For example, if, in the previous Sprint Retrospective, the Scrum team decided that they need to do a better job of asking if anyone needs help before they start working on a new Product Backlog Item, this is the time in Sprint Planning where you would figure out how you would accomplish this improvement. For example, the team might decide that, at every daily Scrum this Sprint, each team member is going to ask for help if they need it and every member is going to let everyone else know if they are available to help.

When you are finished, your Sprint Goal will state what the team wants to accomplish during Sprint like building a feature or providing services to their customers as well as other goals, like learning goals and quality goals.

The Sprint Goal is an agreement between the Product Owner and the Developers. Both parties must agree to the goal. Once set, the Sprint Goal is not changed during the Sprint.

Now, with the Sprint Goal in place, the Product Owner and the Developers work together to figure out which Product Backlog Items will help them achieve the Sprint Goal and how many of them will fit into the Sprint. This is accomplished primarily by the Product Owner and the Developers selecting the Product Backlog Items, the Product Owner or a subject matter expert explaining the Product Backlog Item and the Developers asking questions about the item until they understand it well enough to incorporate it into the Sprint.

When the Developers decides that the Sprint is full, they work together to decide how they want to build the items. They may need to ask more questions of the Product Owner or subject matter experts. The Developers should consider things like

  • Experiments that might help them understand the items better,
  • Skills that the team may not have enough of to do all of the requested work in the available time,
  • Various solutions for the Product Backlog Item,
  • Different ways they could test the Product Backlog Item,
  • Risks they might encounter and how to deal with them,
  • Documents that must be updated, and
  • Approvals that might be needed along the way.

Finally, when the Sprint plan is created and the Developers is ready to get started, you should do one more thing. The Developers should decide which planned Product Backlog Item they want to start with and then figure out how they want to gang up on the item to get it done.

You’ve got a good Sprint Goal, a plan for improving the team, and a good solid plan for getting work done. Now, go ahead get started! Good luck and make this Sprint amazing!

Click here for more information.