How to Keep Sprint Planning Efficient

You’ve heard the term “sprint planning” before. And if you’re reading this article, you probably already know what it means—so I won’t burn time explaining it. Let’s get into nuance.

One factor that’s been on my mind recently is how much time we should dedicate to sprint planning meetings. There are certainly many different ways to run these; the structure depends on the methodology, team size, what point you’re at in the project, and plenty else. For our work with Project Beacon, we have a large development team and not much time to spare. We’re making constant updates to the products, both incremental and significant, as the COVID-19 pandemic around us continues to shift the landscape of the world. We can’t afford wasted time.

Sprint planning meetings can last hours, and I’ve heard tales they can last even days. While it’s fair to say there’s a near-neverending list of things the PM can do to make sprints run smoothly, the opportunity cost of making sure everyone knows what they should be doing vs. discussing it over and over just to be extra sure can be steep.

As we’ve moved through these sprints for Project Beacon, our process has evolved to favor efficiency above all else. Done the right way, this saves a remarkable amount of time without sacrificing any noticeable productivity. Here’s how we do it.

Prepping for Sprint Planning

By the point you’re ready to have your first sprint planning meeting, you (as the product manager) should know pretty much everything the end user should be able to do for the feature set you’re focusing on. Getting to that point is a series of articles in itself, but for our purposes, let’s assume you have approved designs that have been appropriately vetted by developers. (Our process to get here is normally: requirements gathering → product and developer collaboration with design → comps → feature definition.)

The first step to prepare for sprint planning is to break down every design we have into user stories and definition.

Once you’ve done this legwork, you can focus your first sprint planning meeting (more on that below) on the following goals:

• Establishing a shared understanding of how everything within this feature set should work for an end user
• Figuring out what the team can confidently accomplish during the first sprint

Neither of those are trivial asks, but by this point, everyone in the group is at least somewhat familiar with the feature set since they’ve reviewed comps and collaborated with developers around the nuance of certain proposed behaviors.

During the First Meeting

Review all User Stories

The first sprint planning meeting is different from subsequent ones. The best way to set everyone up for success, and avoid the pitfall of under-planning and over-executing, is to do an inventory and collective review of all user stories to make sure we have all expected behavior covered and defined. For us, that involves a methodical process of bringing up each story (that lives in a GitHub ticket) in a screenshare, and letting everyone read through the acceptance criteria. This is an opportunity for developers to ask clarifying questions, identify edge cases, consider and discuss the more global implications these updates will have, and occasionally to provide suggestions for ways to improve the experience.

During these inaugural feature set sprint planning meetings, I often come away with a list of questions or tasks for our product designers. This is great—it usually means the team’s collective brainpower has identified some handwave-y ambiguity that could turn into a risk during buildout. Those action items should be prioritized as soon as possible so as not to block development.

Estimate

The other part of our meeting is spent attaching estimates to stories. Estimating is a dangerous game, and we don’t always do it, but if you’re staring down an ambitious deadline, everyone agreeing on expectations at the beginning, and knowing that we’re going to hold ourselves accountable, is key to efficiency.

It also introduces some interesting discussions—for instance, if the consensus is that a story could take anywhere from 2-40 hours, that’s an indication that (1) you’re lacking definition or (2) there’s an important decision to be made about the tradeoff (e.g., do we prioritize polish for this story and risk the higher end, or is the MVP version of it sufficient?).

Create Action Items

Next, it’s time to identify the stories the team feels are achievable within the sprint. The estimates are the guides here: for example, if there are three developers, that’s approximately 120 working hours, so you should be able to pick out 120 hours worth of tickets. An important thing to note is that this is an absolutely ideal scenario. It’s nearly unheard of that estimates of this magnitude will be dead on. It’s also unrealistic to expect that every working hour will be occupied with writing code. Meetings, Slack, emails, and plenty of other distractions eat up a notable amount of time.

I have a spreadsheet I use to calculate perfect vs. adjusted available development hours. As you can see, we always try to build in extra time to account for the “unknown unknowns” and distractions, and we are transparent about that with the client.

Once the team has their tasks for the week and all the clarification they need, you can consider the meeting finished. All told, we usually keep this to about an hour.

There are still a couple important steps that still need to happen before development starts in earnest, though. They can still technically be considered part of sprint planning, although they’re not a part of the first meeting.

After the First Meeting

Documentation

The next step for us is to create some documentation. That word is foreboding and can bring visions of long nights writing tech specs, but that’s not how we treat it. For us, documentation is created to serve a few purposes:

• It should be practical knowledge-sharing, in that other members of the team who are not directly involved with the feature set can see what’s happening.
• It should be a north star when someone gets too far in the weeds, providing an omnipresent reminder of what exactly we’re building.
• It should be something that can be referred back to when starting work on a new feature set. There’s often a number of things a team can leverage that have already been built.

The documentation can be light, and is typically spearheaded by one person. What’s been most efficient for us is a group brainstorming session to fill out our template as the first step, and then one person finishes it and shares it with everyone else for formal approval. This typically happens before any code is written.

Breaking Down User Stories

The last big thing to do as part of the sprint is to break down user stories into what we call “dev tickets.” These are the technical things that need to happen to fulfill the acceptance criteria in an individual story.

With the size of our Project Beacon development team and the complexity of the features we’re building, the process of the PM cataloging stories but the developers cutting up the back-end and front-end work into more granular tasks has had the following benefits:

• It’s provided another opportunity to catch gaps in our understanding
• It’s led to fewer bugs
• It’s eliminated any bottlenecks since the process of enumerating the work is now a shared responsibility
• The dev tickets can serve as a de-facto checklist to carry a story (and by extension, an epic) from start to finish

Here’s an example of what our dev tickets can look like:

As part of this process, developers are also responsible for assigning out these dev tickets to whoever is best suited for them—in these situations, usually the person creating the task is the one who will take it on.

Subsequent Meetings

In subsequent sprint planning meetings, the agenda is a little different. You’ve put in the time and effort to build a solid foundation of understanding and have started the actual work—now you can evaluate progress and set the course for the next sprint.

My agenda for these is generally something like:

• Evaluate progress on last sprint’s tickets
• Identify what’s next up
• Gut check on timeline

Evaluate Progress

This is a contained retrospective of sorts, although we don’t spend much time on it unless something has significant implications on what the plan will be for the next sprint. (And frankly, if the first time everyone is hearing about a sweeping issue with a story that is going to greatly impact future sprints, you probably need to establish better communication expectations.) This part of the meeting takes us about five minutes.

Identify What’s Next Up

First, if there is something small that didn’t get finished last week (not uncommon), this is the time to figure out how to slot it into the next sprint. That means something else will have to be pushed out (again, not the end of the world).

Using the same model as in your first sprint, you can approximate everything that the team feels confident in being able to achieve using the estimates you’ve assigned to each story and the available hours. This is also a good opportunity to flag any estimates that seem off now that we have more information.

This is the bulk of the meeting, but since we’ve done most of the planning already, it usually only takes about 20 minutes.

Gut Check on Timeline

It’s helpful to zoom out at regular intervals and see how the team feels about our ability to finish the feature set within the timeframe we initially set. This is often unchanged in the earlier stages of a development lifecycle, but as we get closer to launch, this conversation is more likely to yield some changes to the implementation schedule. And that’s where the buffer time you’ve built into your colorful spreadsheet comes in handy.

This last step takes us five minutes, for a grand total of 30 minutes.

Conclusion

This meeting structure and cadence is not really a wholesale adjustment to typical software sprint planning—it’s more trimming at the margins and frontloading the work so that the ensuing weeks can be focused on development, with occasional formal check-ins to keep everyone on the same page about what needs to be done and how we’re tracking overall.

It’s a process that has allowed us to move with greater efficiency, the exact right level of confidence, and opened up extra time for heads-down concentration. And when you’re building something, especially if it’s to fight a pandemic, you need all the extra time you can get.