What is a Sprint Planning Meeting?
Let's start with the basics. A Sprint in the agile project methodology, Scrum, is when a team works to complete specific task milestones or deliverables within a short time. Sprints are also called iterations; this means breaking a larger project timeline into smaller accomplishable goals within a time frame. A Sprint can last anywhere from one to four weeks. The goal is to have your team working at maximum efficiency without hindering your team's quality of work or mental endurance.
A Sprint planning meeting is a collaborative process where team members meet to determine what backlog of work requests will be added to the next Sprint for the team to work on. Sprint planning meetings mark the start of a new Sprint. Holding these meetings minimizes roadblocks and sets a standard for completing the work during the Sprint. This article will detail how to run a Sprint planning meeting and best practices to ensure you are successful.
Why Are Sprint Planning Meetings Important?
If you are like us, you think running a successful sprint planning meeting deserves its own track at the Olympics. Ok, we jest about the Olympics, but we do believe a sprint meeting deserves its own award. We have found that Sprints are a useful approach to working on projects, especially those of significant size. The benefits of Sprints include:
- More focused work
- Better quality and productivity
- Higher client satisfaction
- Reduced risks and costs
- Higher team morale
This approach is particularly beneficial in software development cycles but can be applied to any project that involves multiple people, including design projects. Working in a six-month to even a year-long project can get tedious and leave team members feeling like no progress is being made - even though there is. Using Sprints has shifted how our team plans and executes work, resulting in more celebrated victories and focused goals rather than waiting for the end of a project. This approach helps keep team morale high and projects running smoothly.
How to Prepare for a Sprint Planning Meeting
To get the most out of your sprint planning meeting, make sure you do a few pre-meeting prep tasks to save time and ensure everyone is on the same page. Here's what to do:
Review Your Team’s Capacity
Before the sprint planning meeting, ensure that your team is available to complete the workload ahead. Confirm all planned vacation time, commitments to other projects, and any other obligations or restraints that will hinder their capacity for a project. In addition to your team's availability, you must confirm that you have all the resources to complete the work. Whether internal or external setbacks, don't send your team into a sprint without the resources required to do their tasks.
We review the previous week's Throughput histogram to understand how many tasks our teams could complete and then look at it through a broader timeframe to understand a good average. In this case, our team uses Nave, a reporting dashboard that displays our team's data. We then look at the Aging chart to understand why tasks took longer than expected and find alternatives to avoid aging tasks. Next, we look at the Cycle Breakdown chart to understand which process states take the longest and why. Then we review the Work In Progress goals for each column (in Asana) so the teams understand how much work they are allowed to do at one time.
Prep Your Backlog
The Sprint leader and product owner should review the backlog before the meeting and come prepared with known events or project timelines for the following week. A product backlog, in Agile methodology, is a prioritized list of deliverables that should be completed as part of a project or product development.
Throughout the week leading up to a sprint planning meeting, the development lead, design lead, and project manager are responsible for prioritizing the backlog. There are a few ways our team prioritizes the backlog:
- Logical flow: Any project, whether agile or a first in first out method, will have some logical flow. The lead and team can determine what order to tackle tasks if they are all the same priority.
- Priority Index Calculator: If you find work with competing priorities, you can utilize the priority index calculator to see an objective rating.
- Class of Service: There will be times an expedited request comes in. If there is a task marked “Expedite,” it should be prioritized above anything else.
Plan The Meeting
The Scrum Master is responsible for setting the meeting details. The details include who will attend, what time and how long, where it will be, and what the team will discuss. The meeting length can vary depending on how many people are involved and how complex the project is. Usually, our team holds 30-minute to 1-hour Sprints, depending on the priority and complexity of a project. However, we recommend that you plan for a maximum meeting length of 2-hours, so you don't waste too much time during the meeting.
Who Should Attend a Sprint Planning Meeting?
It's essential to have the right people in the room with you during the meeting. Attendance at the sprint planning meeting includes the scrum team and key stakeholders involved in decision making. If you're unsure who should attend your Sprint planning meeting, ask yourself who is responsible for making decisions during the Sprint? Or who will have input about what tasks will be delivered in the Sprint? If it's more than just your scrum team, invite them to attend.
The Sprint Leader (Also known as the Scrum Master)
The person who holds this title is the project or group leader. They are there to ensure operations are running smoothly. They assist the agile teams to produce products efficiently and effectively. In our case, it is the project manager assigned to the project at hand. They are responsible for the majority of the pre-sprint meeting preparation. They lead and facilitate the discussion for the rest of the attendees.
Product Owner
The Product Owner is the leader or manager of a function within our agency. For example, this could be the Design Director, Development Lead, or Product Design Manager. They share a large portion of the pre-sprint meeting work with the project manager. They are responsible for understanding their teams' capabilities and prioritizing tasks.
Individual Team Contributors
Contributors are the vital people that will be doing the actual work to complete tasks for a project. The contributors could include devs, designers, researchers, etc.
Sprint Planning Meeting Agenda
At Underbelly, we run five-day Sprints, so let's base our planning meeting on a one-week sprint schedule. Every Friday, we meet internally to plan our sprints and go over the project backlog. Daily, our teams have a Standup meeting to review the tasks scheduled for the day, answer questions, and help unblock team members if something is stopping them from accomplishing a task. We manage all of our work within Asana, which allows us to track progress visually and collaborate timely.
Review The Backlog
During the meeting, you will review the backlog to see what is left to work on and decide together what should be worked on next to keep the project on track.
Estimate Stories
As the team reviews the backlog, each ticket is discussed and estimated. A critical component of the agile method is that each project member has control; therefore, tasks are not assigned. Instead, the project team pulls the tasks for that sprint and gives them to themselves.
The Scrum team should collaborate to estimate the size of each task, often called user stories. By estimating the ticket items, you'll determine how many of the user stories and their priority will fit into the upcoming sprint.
Commit to the Work
The team performing the work will commit to the tasks they pulled for the sprint. You can make this part as formal or informal as you wish. It's worth repeating the tasks pulled for the sprint to ensure everyone is on the same page.
What Happens After Sprint Planning (AKA the Sprint)
After Sprint Planning, the team goes into the Sprint cycle, which lasts five days at Underbelly. Daily our team will work through their task board and pull the needed tasks using the Pull Method, which means utilizing the Queue and In Progress columns in Asana timely.
The individual contributors are responsible for maintaining the Planned Sprint column. Daily, we update tasks on both our project board and team board.
What happens as the team is working
Project Managers and Technical Leads will need to monitor Work in Progress (WIP). Our team does this through Asana to see how many tasks they have in progress. Implementing WIP limits allows us to complete single work items faster by helping your team focus only on current tasks. How do we know when something is done?
Before each project has the same definition of done (DoD), the Asana board is mapped within Nave to reflect the team's DoD. Individual contributors should work closely with their manager if there are further questions regarding the DoD.
You finished all your tasks early, now what?
We require all assigned tasks to be completed before new work starts unless there is an expedited task in the Sprint. Expedited tasks should always be completed first. If you finished your assigned task, check your team board, start from the far right in progress columns, and see how you can add value. Remember, it is always best to finish open tasks before starting new tasks. If tasks in the planned Sprint are blocked due to a dependency, it is best not to start the task until all requirements are determined. Starting tasks without clear required details may result in unnecessary energy waste when the time can be spent helping others on your team.
Should we combine our sprint planning if we have design and development on one project?
Yes, it would be best to combine Sprint planning when working cross-functionally. Participating in sprint planning helps to keep the team aligned and informed. This approach can support the development team in recognizing the rigor of the design and research process; consistently seeing and hearing about the design work required for each item will help cement buy-in later on for new approaches and suggestions for changes. Remember that the user stories discussed in sprint planning are intended to be placeholders for further conversation and collaboration between design and development. Don't just attach designs to user stories and then throw them over the wall and hope for the best; stay engaged with your team during the current Sprint and be available for questions or discussions.
Best Practices for Running a Successful Sprint Planning Meeting
- Never count your backlog as fully completed. It is constantly changing due to the iterative nature of software engineering and design projects.
- Continually reprioritize, add new details, and adjust estimates as the product moves through the various stages.
- Measure your team's capacity by how my backlog items they can complete during a sprint period under normal working conditions.
- Create a separate sprint planning meeting for each team functionality within your agency. Ex: Product Design, Branding, Development, etc.
- Each task within the backlog is best achieved by having a detailed user story to guide your project goals.
- WIP limits are considered an essential prerequisite for delivering value to your customer as fast as possible. Too much WIP confuses priorities, causes frequent context switching, and increases overhead.
- If all tasks have a Service Class of Standard, pull the oldest tasks in progress first. First in, first out if the Service Class is the same.
- Start each Sprint Meeting by acknowledging and celebrating your team's progress from the previous Sprint.