Sprint Planning

Avi Siegel

•

9 min read

What is Sprint Planning?

Sprint Planning is a recurring ceremony used on Agile teams where the engineering manager (EM), product manager (PM), and development team prepare for and ultimately start the next sprint. The process gives the team the space to go through any necessary task review before making final decisions on what work should be completed within the sprint, based on priorities and team capacity.

What are the goals of Sprint Planning?

The primary goals of Sprint Planning are to:

  • Begin a new sprint, targeting the right amount of the right work for completion

  • Ensure the upcoming work is well understood by the team

  • Ensure the engineers understand the relative priorities of the tasks pulled into the sprint

What is involved in the Sprint Planning ceremony?

Sprint Planning is a typically 1-2 hour meeting during which the PM will lead the team through filling the to-be-started sprint with the appropriate amount of work. This will consist of the below activities, which will be performed as a team.

Review capacity

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

If your team uses points as the task estimation strategy of choice, this will go as follows:

  1. Review reports from recent sprints (e.g., burndown charts, velocity reports, or wherever you can see point completion totals), and use your best judgment to determine the appropriate target for the number of points of work the team is currently capable of completing within a sprint

  2. Discuss any non-standard non-working time that will impact engineers’ availability to do work (e.g., vacations, company holidays, offsites, work travel, etc.) - subtract an equivalent amount of points from the target

  3. Review work being carried over from the recent sprint - for unstarted work, there will already be an estimate, and for any already-started work, allow the engineer assigned to the task to state how many approximate points of work remain to be done - subtract these points from the target (the remaining total will be the amount of points of new work you can pull into the sprint)

Pro Tip: Check calendars for unexpected (or unremembered) out-of-the-office time. If you didn’t realize a company holiday was coming up, or an engineer forgets about their upcoming doctor appointment, you’ll be going into the sprint already behind.
Pro Tip: Do not change the official estimate on already-in-progress tasks. While it may feel ideal to do this so that the sum of task estimates for the sprint is more accurate, the result would be that points are “lost” in the reporting.

Revisit priorities

The product manager will enter Sprint Planning with thoughts on what they believe is most important to get done within the next sprint. They will be balancing a myriad of competing priorities, such as:

  • Expected timelines for features

  • Platform stability, reliability, or security concerns

  • Bugs

  • Support requests from users and the customer-facing team

  • Short-term vs. long-term business needs

Note that Sprint Planning is not the place to debate this prioritization. Rather, the PM should be intimately familiar with all competing priorities so they can make gut calls and explain them (at a high level) to the team.

Pro Tip: Utilize Sprint Prep meetings to ensure the PM and EM are on the same page as to priorities. If there is any disagreement, that should be hashed out before Sprint Planning, not during.

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. The product manager should know how to best balance competing priorities; they’ll have to make the final call.

Refine tasks

Tasks need to be fully groomed before they can 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 need to be refined during Sprint Planning. For example:

  • Bugs may have been reported between Backlog Grooming and Sprint Planning

  • Tasks may not have been completely refined during Backlog Grooming (either due to additional details needing to be added to tasks, or perhaps most likely because the team ran out of time before refining all tasks)

  • Tasks may have been groomed long enough ago that the team has forgotten the key details of the work, or the scope of work has changed due to outcomes of other work - while it isn’t necessary to completely re-groom such tasks, it may be worth reviewing the details and giving the team the opportunity to speak up if they think the estimate is off-base given any changes to the product or understanding since grooming first was completed

Pro Tip: If you do end up needing to groom additional tasks, be well prepared to discuss all such tasks. Any refinement done during Sprint Planning (instead of Backlog Grooming) takes away from the core activities of Sprint Planning.

Fill up the sprint

With knowledge of how much work can be pulled into the sprint, the relative priorities of tasks, and any relevant goals for percentage splits of different types of work, all that’s left to do is pull in tasks one-by-one until the sprint reaches the calculated limit.

Note that this does not always go as smoothly as it sounds like it should. When confronted with forced stack ranking of tasks, the product manager may have to make last minute decisions on which tasks are truly more urgent than other tasks. At the end of the day, it’s on the product manager to make these calls.

Pro Tip: Some teams like to pre-assign engineers to specific tasks during Sprint Planning. Others like to leave all tasks unassigned so that any engineer can pick up the next-most-important task overall (instead of their specific next-most-important task). Both methods have their pros and cons. Before you decide which direction to go, it is important to note that engineers are not fungible. If you have a team of engineers who all have the same exact skillset - congratulations. If you don’t, then capacity planning will be much easier if you assign tasks to specific engineers, so you can visually see whether each engineer has a full sprint.

Final discussion

Before officially declaring the end of the meeting, open the floor to final comments regarding the likelihood of completing all work pulled into the sprint. This is the last chance for everyone to speak up before the proposed work becomes the work that is expected to be completed.

Pro Tip: It can be illuminating to take a show-of-hands survey on how comfortable the individual engineers are with the expectations for the sprint. Ask the question out loud, and have everyone either hold up a thumbs up/down pose, or a number of fingers 1-5 based on how confident they are that the sprint will be completed. If too many people rate confidence too low, it may be worth pulling out some work. If too many people rate confidence too high, it may be worth considering pulling in some additional work. Likely, there will be a healthy mix of confidence - and that is okay.

The final action to take is to officially start the sprint. The product manager or engineering manager will do the honors.

Who should attend Sprint Planning?

Sprint Planning is attended by only the engineering and product team members that will directly be participating in the sprint. The following individuals should be invited:

  • Product manager (to lead the meeting, provide context, and make final decisions on priorities)

  • Engineering manager (to provide technical context and speak to engineering team priorities as necessary)

  • Engineering team (to understand the objectives of their work and collaborate on any last minute task refinement)

Note that some companies prefer to have the EM lead the Sprint Planning session, since completion of the sprint is ultimately owned by the engineering team (and the EM specifically). On the other hand, some companies prefer to have the PM lead the ceremony, since the final decisions on priorities come from them. Whichever works best for the team - EM or PM - is fine.

How should the team prepare for Sprint Planning?

All invitees should come to Sprint Planning ready to discuss any tasks that may end up fitting into the sprint.

  • Any as-yet ungroomed tasks will need to be discussed in detail and groomed

  • The vast majority of tasks that have already been groomed should not warrant conversation, but some may elicit additional discussion, especially if they weren’t groomed recently

Note that until the previous sprint is officially over, it is unclear where the line will be drawn regarding how much work toward the top of the backlog will fit into the next sprint. As such, everyone should err on the side of extra preparation. That said, do not bend over backwards to know everything about every ticket - you’re looking for efficiency, not picture-perfect memorization.

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

Product manager

The PM must come to Sprint Planning with a pre-formed idea of which tasks they want to, and think, will fit into the sprint. They need to know which tasks require further refinement, and more broadly which tasks need to be discussed with the team (in what order) before they can be pulled into the sprint.

The PM will also need to be prepared to make gut call decisions on priorities. After Sprint Prep, they will have a good idea of what work will probably fit into the sprint - but there is inevitably variability that occurs within Sprint Planning which will force a final call by the PM. To make such decisions, the PM needs to be able to weigh all competing priorities at a moment’s notice.

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. They will be able to more insightfully bring the team up to speed on these than the PM (especially if the PM is non-technical).

Engineering team

Before Sprint Planning, as they would before standup, each engineer should double check that all tasks which they personally own within the to-be-closed sprint are properly updated. The most important item is to ensure the current status of each task is correct (with special attention paid to making sure tasks are marked as completed as applicable). Also, recent comments should be left regarding the current state of tasks, teammates should be mentioned who may have action on them (but may have lost track of their involvement), etc.

Engineers should also review tasks toward the top of the backlog (i.e., the ones most likely to be pulled into the sprint). Minimally, they should skim these to ensure they are familiar at a high level (with extra attention paid to any tasks that may still need to be groomed). Wherever applicable, if they have renewed questions about any particular set of work, they should come to the meeting ready to discuss.

Finally, they should review their personal calendars to ensure their availability is accurate - doctor appointments, scheduled vacation time, etc.

Best practices for Sprint Planning

  • Focus is key. While balancing priorities, the product manager should do their best to ensure the team can maximize focus during the sprint, with an eye toward increasing and maintaining momentum. Some companies like to state formal sprint goals to force this focus - to many, this can become a redundant list of tasks compared to those already listed in the sprint, but if sprint goals help your team, they can be utilized.

  • Be hyperaware of the line separating PM and EM responsibilities and control. It is the responsibility of the product manager to determine priorities of what goes into a sprint (with feedback from the team of course). It is the responsibility of the engineering manager to determine sequencing of tasks within the sprint (again, with healthy collaboration with the team). In practice, this means that (except in the case of escalations), the Sprint Planning ceremony is the final opportunity for the product manager to determine what tasks the team should work on for the next x weeks. It also means the PM is placing a high amount of trust on the entire engineering team to complete what they said they would complete.

  • Do not let Sprint Planning become yet another Backlog Grooming. This generally occurs because too much time is spent on refining each task within the confines of the Backlog Grooming ceremony, such that not nearly enough work is groomed, necessitating that that activity be completed at the last possible moment, during Sprint Planning. The simplest way to avoid this is by timeboxing grooming. Of course, the core of that should be done during Backlog Grooming - if any of that makes its way into Sprint Planning, it is that much more important for timeboxing to be strictly adhered to.

  • The PM and EM should be tightly aligned on the sprint priorities well before the ceremony begins. Sprint Prep is not a formal part of the Agile methodology, but if employed, is a perfect opportunity to gain such alignment.