What is the purpose of Sprint Planning?
Sprint planning is a one of the five events in Scrum product development and plays a super important role in ensuring success. Sprint planning is a structured approach that enables teams to plan and execute work in a collaborative manner. It’s an event that enables teams to identify and prioritize tasks, set goals and objectives, and establish a plan for how they will achieve them.
In this article, we’ll go through the purpose of sprint planning, its key components, and some good practices for running a successful sprint planning event. So hopefully you can understand the purpose of sprint planning, and how to do it well.
The Purpose of Sprint Planning
Sprint planning is a crucial event in the Scrum framework. Its purpose is to build a common understanding of the work that needs to be done, and to create a plan for the team to work together and achieve their objectives. The purpose of sprint planning can be broken down into the following key components:
Establishing Goals and Objectives
The main purpose of sprint planning is to establish goals and objectives for the upcoming sprint. The team should have a clear understanding of what they want to achieve during the sprint – i.e. what success looks like. This ensures that everyone is working towards the same goal. And helps to align team efforts towards a common objective.
Try to make the sprint goal short, meaningful and related to the business purpose of the product. Think about the product goal, and the upcoming stages on your product roadmap.
Try to avoid generic sprint goals like “complete all the backlog items” or “get everything done”. Make them instead relating to a high-level business function or capability of the product.
Prioritizing Work
Another important purpose of sprint planning is to prioritize the backlog items for the sprint. The team should identify the most critical backlog items and discuss which ones they might tackle first. This enables the team to focus on the most important work first and ensures that progress is being made towards achieving their goals.
Creating a Sprint Plan
Sprint planning also involves creating a high-level plan for how the team will achieve their objectives. The plan should identify the tasks that need to be done, and the overall approach for completing them.
You don’t need to go into details about who will be doing which item. Scrum works better with a “pull” system, where people pick up tasks from the sprint backlog as and when they are free. (This “pull” idea comes from Lean and Kanban).
So the plan is more about the overall approach – what items are you prioritizing, how are you managing quality and risk, when are you likely to deploy, etc. – rather than a project plan with tasks and timelines.
So you don’t want a plan like “Person X will do task Y for the first four days, person Z will do task C for the following three days”. You want a plan more like “we will focus to start on the remaining data migration work, then move on to closing out the new UI issues and API integrations”.
The Sprint Backlog
These things the team has created – the sprint goal (the “why”), the backlog items (the “what”) and the plan for the sprint (the “how”) make up what we call the “Sprint Backlog”. And the team will continually refer to this as they work on the sprint. All of this is explained pretty clearly in the Scrum Guide.
Main parts of Sprint Planning
To do sprint planning well, you have to make sure to do these following bits well.
Review the Backlog
Before starting sprint planning, review the backlog to ensure that you’ve got a clear understanding of the work that needs to be done. The backlog should already be well-defined and prioritized. This will make selecting the right backlog items much easier.
I have a “no surprises” rule for sprint planning. Developers should not be asked to include backlog items that they haven’t seen before! Regular backlog refinement activities can help with this. It makes sprint planning go much more quickly and easily. I would rather have a 90 minute backlog refinement and a 90 minute sprint planning event than a three hour sprint planning event. A lot of other people would too!
Set sprint goals / objectives
During the sprint planning session, the team has to craft a sprint goal for the upcoming sprint. We talked above about the importance of this and how it has to relate to the product goal and roadmap. Don’t skip it!
If you’re struggling, look at the product goal, maybe the product roadmap, and look at the backlog items. Discuss with the product owner about what the real priorities for the business are.
Break down sprint tasks (optional!)
The team might want to break the backlog items further into small tasks that can be completed. This is actually an optional step, and I often don’t do it. Creating tasks means more administration in your work tool (and less actual product development). It also makes the board / sprint backlog harder to read. It can also encourage people to follow a component mindset and focus on completing small bits, rather than full vertical slices.
E.g. you might end up at the end of the sprint with a UI task done for story X, an API task done for story Y, and a database task done for story Z. Which means you’ve delivered nothing!
The objective is complete backlog items, which are atomic independent pieces of value. If you hadn’t broken the stories into tasks, the team would have (as a group) tackled one of the three stories, and done all the work required to get it to Done.
So be careful about breaking backlog items down into tasks. Make sure you are laser-focused on delivering pieces of concrete value, not just ticking boxes. Otherwise, breaking down backlog items into tasks could create more problems than it solves.
Estimate Effort
Unless you are doing No Estimates, the team should have estimates against each backlog item that are candidates for the sprint backlog. The Scrum guide doesn’t say much at all about this. In the section on backlog refinement, it just says “This is an ongoing activity to add details, such as a description, order, and size.”
So you don’t have to add a size – it even says that there are different attributes that you might want to put against backlog items. And that those attributes vary with the work domain. Ok then – it seems it’s up to you.
But let’s say you are doing estimates (and most people are). You could do the estimating in sprint planning. But I like to do some or most of it in backlog refinement, sometime during the sprint.
The reason is simple – I like sprint planning to be short and punchy. I don’t want them to go for four (or maybe eight!) hours. Like the Sprint Guide says. Nobody got time for that!
I recommend you front-load some of the estimation, and do a bunch in backlog refinement. That way, when you get to sprint planning, you won’t have much to do. You can just revisit them, and maybe put estimates on ones that have come up recently.
Summary
Sprint planning is one of the most important parts of Scrum. And a lot of people don’t understand it or do it wrong. So hopefully you now know that the purpose is to choose a goal, select some high-priority backlog items that support the goal, and create a high-level plan for the team. So they can complete the goal and deliver some value. Nice one!
Do you have any other thoughts or questions on this? Let me know in the comments!
