It’s time to get things done and hand over the project to the programmers. But before they get their hands dirty, someone must plan the Scrum sprint or iteration. The Sprint Planning meeting is one of Scrum’s ceremonies, and it's the sprint's opening event. 🎬
Let's walk you through the event and explain how to prepare and hold one successfully. You'll also learn who participates in Sprint Planning and why the meeting is so important.
What's a Sprint Planning meeting?
Sprint Planning is a Scrum meeting. It kicks off a sprint, so it occurs on the first day of a new sprint. If applicable, it should occur after the Sprint Review and the Sprint Retrospective from the previous iteration.
Sprint Planning aims to decide the deliverables for the upcoming sprint and define a plan to develop the work.
Can you imagine a successful project without planning? 🙅 We can't either, so we don’t start a Scrum sprint without planning it.
To plan a Scrum sprint, you need to decide:
- The sprint's duration — remember that a sprint is a timebox
- The sprint goal, which is its purpose and represents the product increment's value to the customer
- The work that the Development Team can complete during the sprint, what work items the team should do first to achieve the sprint goal, and how long they should take considering the team's capacity
Additionally, Sprint Planning should motivate the team and set realistic expectations.
By the end of the Sprint Planning meeting, the team must produce the following outcomes:
- A shared understanding of the sprint goal. This goal is the guideline for evaluating the Development Team's work once the sprint is over.
- The Sprint Backlog. This artifact represents the conversation between the Development Team and the Product Owner on the to-do work. It's the result of a balance between customer value and development effort.
Now, each Sprint Planning meeting requires some preparation. Read on about who should do it and what it entails.
How do you prepare for Sprint Planning?
The Product Owner should follow these steps to set the foundation for successful Sprint Planning:
- Combine the output of the previous Sprint Review, feedback from stakeholders such as management and customers, and the product vision
- Update and, if necessary, refine the product backlog
- Know the customer value that the development team needs to create in an increment
So, once all the preparation is over, it's time for the Sprint Planning meeting to take place.
How should the meeting go?
- The Product Owner indicates the Product Backlog items — and corresponding priorities — that they consider the next sprint's best candidates. Items can be user stories, tasks, or bugs. The Product Owner proposes those items according to customer value and product vision.
- Based on effort estimates and the Product Owner's proposal, the development team selects the product backlog items to work on during the current sprint. By promoting those items to sprint backlog items, developers agree on the sprint goal with the Product Owner.
- Although optional, the team might discuss dependencies between items and who should work on each one of them.
Very few steps, right? However, some practical actions should add on to these steps. Discover what those actions are below.
How do you execute a successful Sprint Planning meeting?
1. Limit the meeting's duration. ⏳ Sprint Planning shouldn't take longer than 1-2 hours per sprint week. That means the meeting shouldn't take more than 2-4 hours for a two-week sprint.
2. Let the Scrum Master be the guardian of time. They're the ones responsible for ensuring that the meeting happens within the defined timebox.
3. Hold the meeting on the same day and at the same time every time. 📅 Team members can be quite busy and have full agendas. That's why reserving a slot in every participant's agenda is a good practice.
4. Define valuable, clear outcomes. 🎁 Those, together with a clear sprint backlog, increase the Development Team's motivation. Producing the right outcomes is pure satisfaction, and a clear work plan is the recipe to achieve that.
5. Make sure that the Scrum Master guarantees these things. First, that the conversation between the Development Team and the Product Owner is fruitful. They should all agree on the sprint goal. Second, that the developers make good choices when moving product backlog items to the sprint backlog. Selecting an item that is feasible for the sprint duration, team capacity, and workload is a good choice.
It might seem easy, but this is not all there is to do during Sprint Planning. There's a bunch of things to avoid.
If we were to give you some advice...
Make effort estimates against the development team's capacity. To decide on the amount of work that the team can accomplish in a sprint, consider the team's capacity. (And remember, estimates are just that — estimates.) Developers consider their previous experience, yet each sprint is unique and might change over its course. However, considering team capacity improves the accuracy of effort estimation. Additionally, story points might help the team with effort estimation.
Consider that the development team's ability to estimate should improve over time. Therefore, the team should not critique less accurate effort estimates after the sprint. Otherwise, the team will take much longer to estimate or provide much bigger estimates next time.
Don't try to plan every single thing during Sprint Planning. Leave the idea of coming up with the most complete, perfect Sprint Backlog ever at the front door. After all, Scrum is all about flexibility, and "Better done than perfect." So, a Sprint Backlog that’s complete enough to get developers started is just what it needs to be. Remember that solving complex problems requires a learn-by-doing approach, which turns planning into an equally complex job.
Figure out a realistic expectation for the sprint's outcome. Setting unrealistic expectations for the increment that the development team can produce over a sprint is not a good idea. It might make developers frustrated that they couldn't deliver, which can seriously affect their motivation and performance. On the other hand, realistic expectations set the team for success and a sense of accomplishment. Besides, they facilitate the conversation between the developers and the Product Owner so they can agree on the sprint goal.
Have a well-refined product backlog. It must be detailed enough to allow the Development Team to understand what the work items are about. You don't want to waste precious Sprint Planning time splitting work items into a maximum of one per day. Define and follow a backlog refinement process and ensure that Product Backlog items meet your definition of ready.
Propose a clear sprint goal. 🎯 The Product Owner must be very clear on the expected customer value for the increment. Otherwise, the development team might choose a set of product backlog items that don’t relate to one another. The result could be unexpected outcomes and a low sense of accomplishment.
Clarify the definition of done with the Development Team. Knowing what work done means in the current sprint helps the developers meet the expectations. That's because they can better understand what to do to create the increment. Also, a clear definition of done makes the Development Team more confident when estimating effort.
Strong Sprint Planning makes your project stronger
If you're following the Scrum framework, Sprint Planning is not a choice. Nevertheless, if you ever feel tempted to skip it, bookmark this article and read the following. 📑
It's easier to understand the sprint goal, to-do work, and sprint outcomes with a successful Sprint Planning meeting. If the team doesn't know where it's heading and how to get there, it gets really tough to satisfy customer needs. It's equally hard to deliver your customers valuable increments if you don't organize work by priorities.
Sprint Planning is about instilling clarity and organizing work before it's too late in the iteration. It's also about involving the whole team in preparing for all the effort that a sprint demands. A note: Keep in mind that a sprint plan must fit into a sprint's timebox and consider the team capacity.
Easy Agile User Story Maps for Jira is perfect for Sprint Planning. It's a fast, straightforward, visual, and collaborative tool that allows you to:
- Drag items directly from the product backlog onto the user story map
- Register effort estimates in user stories
- Edit story point estimates
- Prioritize user stories in each sprint by ordering them inside the respective sprint swimlane
- Analyze sprint statistics to ensure that the planned work doesn't exceed the team's capacity and the sprint goal is realistic
- Visualize what the team will deliver and when by arranging user stories into sprint swimlanes
Let us know if you have any questions with Easy Agile User Story Maps for Jira. We highly recommend it to your Scrum project, and our customers recommend the same.