Imagine you are planning a two week vacation. Your goal is to relax, dip your toes in the sand and have a drink. This is your Why of your vacation. So you create a plan to meet your Why. You book an all you can eat and drink resort in Mexico, book a flight, book Uber, etc. You also want to book some activities in the resort so that you can relax and enjoy. These items are the what of your plan. Now imagine you go there with your family and your children. Perhaps your family will help with the booking. How are all the activities going to be enjoyed by each person. This is the how you will achieve the goal.
What you just accomplished is the Why, What and How of planning your vacation.
Sprint planning in scrum also has a why, what and how. At the end of the blog I will share 5 things most team get wrong when they plan a sprint
What is Scrum?
Scrum is an execution framework for the team to deliver a portion of the product in a time frame of upto a month. This duration of time is called a sprint in scrum.
Similarly, at the start of the sprint, the team meets to plan the sprint before they can execute on the work of the sprint. A sprint planning event is up to 8 hours for a one-month sprint. The input to the event is an ordered product backlog, past performance and capacity of the team for the sprint.
The product backlog consists of items in the product backlog (Product Backlog Item). The product backlog item can be features, user stories, technical tasks as well as bugs. The top of the product backlog contains items that will deliver the maximum value to the customer.
The product owner offers a set of product backlog items (PBIs) from the top of the product backlog. Typically the product owner might have an overall objective that he or she proposes.
The developers collaborate with the product owner to create a sprint goal.
What is a Sprint Goal?
A sprint goal is a single-line statement of the customer is going to get at the end of the sprint. Let’s say my family and I are going on vacation to Florida for a week to enjoy the beach. Our family goal for that week would be to “Enjoy the beach to rest, relax and rejuvenate”. To accomplish this goal we will need to take an Uber to the airport. We will take the flight from the airport to Florida, we will take another Uber to the hotel, etc. These become the items we have to do in order to achieve our goal. Now if we have an issue with the flight, we will have to change our plans and find an alternative. Perhaps take a delayed flight or drive to another airport to take a different flight or drive to Florida. In this case how I achieved the goal changed but my goal did not change.
This is exactly what a sprint goal is. It gets the team focused on a set of related tasks that deliver the goal. It’s their north star for the sprint.
Next, the developers look at the scope of the work proposed by the product owner. They take the number of items based on their past performance and capacity. The team pulls the items from the product backlog to the sprint backlog. The sprint backlog contains the sprint goal and the items that the developers have chosen for the sprint. The sprint backlog is owned and protected by the developers
Past performance is the amount of work done by the developers in the past sprints. I recommend my teams consider looking at an average of their past performance over three to five sprints. This number might change over time and so they can take on the amount based on this trend over time.
This is the capacity of the developers available in the sprint. Some members might have time off, they might take some time for training or some other administrative tasks in their organization. So each sprint the developers should take an account of what their combined capacity is for that sprint.
The developers now design the work they have chosen and are part of their sprint backlog and break down the work into smaller tasks that the developers can self-assign and work together to deliver each item by priority.
While considering the what and the how, the developers also confirm that the sprint goal can still be met by the items they have chosen and how they plan to deliver them. The sprint backlog now contains the sprint goal, the product backlog items and the tasks along with who is doing what tasks.
Join us in our next Certified Scrum Master Course or Certified Product Owner Course to learn more about how you can effectively plan your sprint. Scan this QR code or check out the links in the description below.
There are 5 things most teams get wrong when they plan a sprint
They don’t have an agenda and they don’t time box each of the why, what and how. If this is you, then please rewind this video and consider using the agenda that I described in the beginning of this video
2. Missing Product Backlog Refinement
This is the first time that developers get to see what is coming up in this sprint and they spend most of the time with the product owner clarfiying the requirements and estimating. The items in spring planning should be ready meaning they should be clearly understood and estimated before they come to into sprint planning. How can the scrum team do that? They do that using product backlog refinement, an activity in Scrum focused on getting items ready for the next sprint or future sprints.
3. No Sprint Goal
The scrum team does not create a sprint goal. The goal is arguably the most important part of sprint planning. The typical sprint goal could be performance related to “The customer experiences the response of the system in sub seconds”, or “the customer can search for new movies and shows easily” a goal that amazon prime should have. I can never find anything new or upcoming whenever I go to the amazon prime app on my TV. Or it could be “Customer gets an update for the self driving in a Tesla Model”. The sprint goal is an indication of all or most of the items in the sprint backlog. The sprint goal forces the scrum team to collaborate and work on a single set of features that deliver on that goal. The goal also keeps them focused on what they want to achieve and gives them an opportunity to negotiate scope as needed.
4. How to calculate the number of items to plan for the sprint
How many items do we pick for the sprint. This depends on past performance which could be an average of how much the team has delivered over the last 3-5 sprints. Another thing to keep in mind is the capacity of the team, the capacity of the team is the number of hours your team will spend on the work for this sprint. Now that could change from sprint to sprint because some of your team members might be on vacation, go for training or are out sick.
5. Developers pull the items
This is the most important so listen carefully. The developers in the scrum team pick the number of items they want to work in the sprint based on past performance and capacity. They pull the items from the product backlog to the sprint backlog. The product owner does not repeat does not push the developers deliver more that what the they have pulled.
So, That’s all about sprint planning, not different than any other planning your vacation