Within the agile framework there are a number of ceremonies that different members of the “scrum” team participate in such as prioritization, backlog refinement, sprint planning, daily standups and retrospectives. These ceremonies help to drive success by focusing on the team over processes.
In this article, you’ll learn about the ceremony called sprint planning. You’ll read about what it is, how to run an effective sprint planning ceremony, common pitfalls to avoid, and more.
Sprint planning is one of several ceremonies teams conduct when practicing agile development. During sprint planning the team aligns on what they want to accomplish in the upcoming sprint, how much available time they have to commit to work, and what actual work can be accomplished.
Typically product, engineering, and a scrum master are present. Some teams opt to have their QA and UX designer also participate as part of this ceremony. I find it is extremely helpful to have UX and QA present so that the planned work is discussed and any additional UX gaps or questions can be resolved.
There are several ceremonies that take place in the week leading up to a sprint planning session, such as prioritization and estimation. You need the details outlined in those ceremonies in order to run an effective sprint planning ceremony. Let’s take a closer look at the details of those two ceremonies.
A prioritization meeting takes place typically a week before a sprint planning ceremony. The prioritization meeting involves a scrum master, product manager, ux designer and engineering lead.
In this meeting there’s a collective discussion on key projects the team is working on, overall status of those projects, and a proposed agenda for the next sprint. Any new work, product or technical questions are surfaced for the leads to work through before bringing the project to the larger team.
Before a backlog refinement it is up to you to curate the tickets you want the team to estimate. This includes making sure all the details of the work are spelled out in the ticket, any designs are attached, and a clear definition of done is determined.
During backlog refinement, the team goes through the tickets one by one and gives an estimate on the level of effort for the ticket.
So now that you’re aligned with your leadership team on key projects, the goals you want to achieve, and the value of the work involved, you’re ready for the sprint planning session. Sprint planning is typically run every other week in traditional agile environments.
At the beginning of the session the PM reviews with the team the goal of the sprint, or objective the team aims to achieve during the upcoming sprint. This important step helps provide for the team clarity up front and gives the team a clear focus.
Once the sprint goal is discussed, the next important piece of information is to understand what resourcing looks like for the next sprint. The collective team discusses anything that may take away from traditional sprint work, like on-call shifts, time off, holidays or any unfinished work from the previous sprint. This information is vital to obtain up front so that the team is not over committed with work and can realistically achieve the goal set.
Now that the team understands the goal and how much capacity for work there is in the next sprint, it’s time to select the stories. At this time the backlog is pulled up and the estimated work (from your backlog refinement session) should be prioritized in order of importance. The stories and tasks are pulled in based on the capacity outlined and assigned out to the development team.
While the task of running a sprint planning ceremony seems pretty straightforward, a lot of work goes into the planning process both before and during the ceremony. Here’s a template you can use as a guide to ensure you are well prepared for the meeting:
While planning and running a sprint planning ceremony sounds straightforward, there are some important challenges that can occur that can derail the best of plans. Here are three of the main challenges that can arise with tips on how to avoid these sticky situations.
It’s important that the larger scrum team stays in the loop on the work committed for the quarter. In fact, over communication here is key. I can’t tell you how many times I have heard developers question projects, goals, and why they’re doing the work they’re asked to do.
These heavy conversations take away valuable sprint planning time. To avoid this situation, make sure to keep the team in the know regularly of the projects, any timelines committed, and larger product plans. To be safe, review this information at the beginning of the sprint and as things change.
The next biggest challenge is around the actual estimation that typically occurs before sprint planning. Not thoroughly understanding the scope of the ticket or trying to pack too much work within a single ticket leads to poor estimates, which leads to unachievable work during a sprint resulting in rollover work and putting the project at risk for delay.
The best way to avoid this is to thoroughly breakdown the work and make sure the team asks any questions or outlines any unknowns. Having a ticket estimated at a 13 for example means that the story is huge and likely can be broken down into a series of bite-sized tasks.
Understanding exactly what the team can achieve and what external outliers could occur during the next sprint will help you get a clearer picture on how much work the team can actually commit to. The challenge here is that there are still a lot of unknowns. I’d say try to leave some breathing room in a sprint for those ad hoc changes, however with tight project timelines I know realistically that is hard to do.
Just keep in mind as you plan your sprint work and goals there are random things that can come up. Your developers may call in sick, another team may need your team for code reviews or consulting, there could be an incident that pops up taking up much of the team’s time. While you can’t foresee these types of things happening it’s still good to keep in mind these situations and ensure the team isn’t overpromising on something that they feasibly cannot deliver.
Here are a few additional tips to keep in mind for your next sprint planning ceremony:
Sprint planning is essential in running an effective team and project timeline. Sprint planning keeps the team aligned on the goals for that sprint, gives them an understanding of the project, and helps keep everyone accountable for deliverables and timelines.
Make sprint planning something the team looks forward to and wants to participate in. Make sure you celebrate with the team when sprint goals are achieved. Also, increase participation from the team by coming up with some fun naming convention for each of your sprints. I’ve used favorite movies, songs that start with A-Z, celebrities etc.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Dipto Chakravarty, Chief Product Officer at Cloudera, talks about how it takes rigor to design complex technology and user experiences.
As an alternative, this article outlines a case against MVPs, drawing on my own personal experience in the realm of product management.
No product team starts out trying to harm users. However, harm still happens, and often not from one big decision.
This article assesses the reality of story points, including their promise and where they went wrong, and then offers a potential solution.
Learn more →
