Sprint Prep

Avi Siegel

•

8 min read

What is Sprint Prep?

Sprint Prep is not an official ceremony within the Agile methodology, but it adds a missing connection point for the product manager (PM) and engineering manager (EM) to get fully aligned ahead of Sprint Planning with the broader team. Sprint Prep typically falls the day before Sprint Planning to ensure the PM and EM have as much information as possible before setting out their plans.

What are the goals of Sprint Prep?

The primary goals of Sprint Prep are to:

  • Have (more than) enough tasks ready to pull into the next sprint to completely fill it up with work for the entire team

  • More efficiently utilize people’s time by allowing the PM and EM to take care of as much preparation as possible between just themselves, before involving the rest of the team in Sprint Planning

  • Enable Sprint Planning to run smoothly, without unnecessary debates that can sideline the meeting, by ensuring the PM and EM are aligned on priorities

What is involved in the Sprint Prep ceremony?

Sprint Prep is a typically 30-60 minute meeting during which the PM and EM get on the same page as to which tasks will likely end up fitting into the next sprint. Together, they will go through the following activities.

Review expectations for the to-be-closed sprint

Run through all unclosed tasks in the ongoing sprint to determine which will likely be closed by the end of the sprint, and how much work will likely be left on the remaining tasks. The EM will provide their knowledgeable best guesses for said remaining work.

The goals here are threefold:

  • Capacity planning: Understand how much work will be leftover (and thus take away from the amount of work that can be pulled into the next sprint)

  • Prioritization: Understand how projects are progressing, to help the PM with prioritization decisions

  • Dependencies: Understand which tasks will not be able to be pulled into the next sprint due to blockers not yet being completed

Pro Tip: Keep track of which work will be leftover for each engineer. Engineers are not fungible, which means you should separately plan for each engineer’s individual workload for the upcoming sprint.
Pro Tip: This is an opportunity to pay special attention to any work that is taking significantly longer than expected. Don’t simply note that the work isn’t done and move on. Ask yourself if the work should be deprioritized or passed off to a more qualified engineer. You’ll want to make such a call behind closed doors, not call someone out publicly during Sprint Planning.

Review capacity for the upcoming sprint

Determine how much work the team should realistically target for completion in the next sprint.

  • Review reports from recent sprints (e.g., burndown charts, velocity reports), and use your best judgment to determine how much work the team is currently capable of completing within a sprint

  • Discuss any non-standard non-working time that will impact engineers’ availability to do work (e.g., vacations, company holidays, offsites, work travel, etc.)

  • Review the conclusions from the previous activity, where you determined how much work would be leftover from the to-be-closed sprint

The goal here is an estimate, so this step does not need to be overly robust (e.g., if your team uses points as the task estimation strategy of choice, it is overkill to do formal calculations here). It’s impossible to be exact, since you won’t have input from the engineers working on in-progress tasks, and there will by definition still be time left in the current sprint for more work to be closed out. Additionally, you will want to be prepared with extra work anyway, in case more work gets closed out than you expected. All said, you should err on the side of low expectations - the worst case scenario will be that you are prepared for discussion that doesn’t come up in Sprint Planning.

Debate & align on priorities

The PM will enter Sprint Prep with an idea of what tasks they want to target for completion in the upcoming sprint. This will include such work as:

  • Feature development

  • Bugs

  • Support requests from users and the customer-facing team

The EM will enter Sprint Prep with a specific focus on what work should be targeted based on their technical perspective. This will include such work as:

  • Platform stability

  • Reliability

  • Security concerns

Note that some companies use formal targets for different types of work. E.g., the team may have targets defined by leadership regarding the percentage of features vs. infrastructure vs. bugs to work on.

Pro Tip: If your company uses such targets, indeed attempt to hit them, but also don’t stress too much about hitting them in an individual sprint. The trend matters more than the percentages of a single sprint.

While Sprint Planning is not the place to debate priorities, Sprint Prep is exactly the place where such debate should occur. The PM will be balancing their view from a myriad of competing priorities. The EM will be more singularly focused on infrastructure needs.

Healthy debate is good here. While the PM is responsible for making the final call on priorities, that does not mean that the EM’s opinion is irrelevant. E.g., if major infrastructure work is needed lest the system eventually collapse in on itself, but the team is significantly behind on the roadmap, this is the time to hash out what needs to be done and when.

Pro Tip: Maximize transparency. Both the PM and EM should say what’s on their mind. If all relevant information is out in the open, the best prioritization decisions can be made.

The final result of this step should be a reprioritized (top of the) backlog, so it is clear to viewers which work is up for discussion for the upcoming sprint.

Plan staffing (with contingencies)

Discuss which engineers will be targeted with which tasks in the upcoming sprint. This list should include:

  • Tasks that each engineer will likely be assigned

  • Tasks that are next in priority, if for any reason the other tasks either can’t be done, are picked up by someone else, or are completed

In other words, the list of tasks for each engineer should be large enough that everyone will certainly have enough work to do - i.e., you shouldn't have to scramble for additional work live during Sprint Planning.

Pro Tip: Consider the importance of focus as you finalize priorities. While certain tasks may technically be higher or lower on the priority stack ranking, it can often be worth allowing engineers to work on highly related tickets, or at least within a small number of product areas, so as to reduce context switching during the sprint.

Refine tasks

Tasks will need to be fully groomed before they can ultimately make their way into the sprint. Despite a goal of Backlog Grooming being that all tasks are pre-groomed before Sprint Planning, it is not uncommon for additional tasks to still need refinement.

For any tickets that may make their way into the next sprint, do as much refinement as possible before Sprint Planning, so you can maximize efficiency of time spent with the team during that ceremony. While it is inappropriate to perform formal task estimation without the broader team, Sprint Prep still presents an opportunity to flesh out content, break down larger sets of work, and reprioritize if needed.

Who should attend Sprint Prep?

Sprint Prep is intended only for the product manager and engineering manager, as its purpose is for those two individuals to get maximally aligned before the next sprint is formally planned with the broader team.

The list of attendees for the meeting is thus:

  • Product manager (to lead the meeting, provide all-but-engineering priorities, and make final decisions on priorities)

  • Engineering manager (to provide engineering priorities and an understanding of individual engineer’s task progress and capacity)

Note that while the PM is technically leading this meeting, it is a meeting between only two people. Either party should speak up whenever necessary to ensure the sprint is adequately pre-planned.

How should the team prepare for Sprint Prep?

All invitees should be familiar with tasks that may be discussed during Sprint Prep (i.e., ones toward the top of the backlog). The bar is higher for the PM in particular, who should be intimately familiar with such tasks, since they are by definition most knowledgeable as to which tasks will be discussed.

Beyond the above note, each role should further prepare as detailed below.

Product manager

The PM must come to Sprint Prep with a pre-formed idea of which tasks they want to, and think, will fit into the sprint. They should prioritize the backlog to represent these goals.

The PM should also intimately understand all competing priorities so that, if the EM provides context that changes what tasks can likely be targeted in the upcoming sprint, they can immediately shift focus to the next highest priority work.

Engineering manager

It is the responsibility of the EM to understand the technical capabilities of each individual engineer, so they can make recommendations surrounding capacity planning and task assignments (as applicable).

The EM should also be prepared to discuss any high priority infrastructure tasks in particular.

Best practices for Sprint Prep

  • Collaborate with and trust each other. If the EM says a ticket is not feasible as written, discuss alternate solutions that still meet requirements. If the PM says a feature is the highest priority for the business, figure out what sacrifices can be made to squeeze it into the plan. If the EM says the system will collapse in on itself if certain infrastructure work isn’t completed ASAP, trust that that’s the case. If the PM is willing to deal with time losses from context switching to make an important customer happy by solving a newfound bug, that’s their call. Work together on everything - you’re on the same team.

  • The EM and PM must be fully aligned. Otherwise, the engineers may question the priorities themselves - and rightfully so. To avoid this, you should agree to disagree (privately), and then agree to agree (publicly). With your different perspectives, you will not agree on every topic or with every decision. Don’t let that disagreement stop you from moving forward (and don’t let it harm your working relationships, either). After you’ve made your points and said all you needed to say, even if it didn’t necessarily go as you wanted, agree to agree when you take the plan to the broader team. Individual contributors need to see cohesion in the plan to get bought into it - if the leaders can’t agree, that will only sow chaos.

  • The purpose of Sprint Prep is efficiency, not control. While a goal of Sprint Prep is for the EM and PM to get as prepared as possible for Sprint Planning themselves, without direct participation from the rest of the team, it is important to note that the purpose is not to shut down healthy debate. Rather, it is to have those debates in a smaller group, with the aim of more efficiently using everyone’s time.