Sprint planning is a timeboxed event within the scrum framework that kicks off the upcoming sprint for agile teams. Sprint planning identifies what tasks will be completed in the sprint and how that work will be achieved.

In scrum, the sprint is a set period of time where all the work is done. However, before you can leap into action you have to set up the sprint. You need to decide on how long the time box is going to be, the sprint goal, and where you're going to start. The sprint planning meeting kicks off the sprint by setting the agenda and focus. If done correctly, it also creates an environment where the team is motivated, challenged, and can be successful. Bad sprint plans can derail the team by setting unrealistic expectations.

What is the purpose of sprint planning?

The product owner describes the objective(or goal) of the sprint and what backlog items contribute to that goal. The scrum team decides what can be done in the coming sprint and what they will do during the sprint to make that happen.

How to run a sprint planning meeting?

The development team plans the work necessary to deliver the sprint goal. Ultimately, the resulting sprint plan is a negotiation between the development team and product owner based on value and effort.

Who are the key participants?

Sprint planning meetings can't be done without the product owner or the development team. The product owner defines the goal based on the value that they seek. The development team needs to understand how they can or can't deliver that goal. If either is missing from this event it makes planning the sprint almost impossible.

What are the inputs?

A great starting point for the sprint plan is the product backlog as it provides a list of ‘stuff’ that could potentially be part of the current sprint. The team should also look at the existing work done in the increment and have a view to capacity.

What are the outputs?

The most important outcome for the sprint planning meeting is that the team can describe the goal of the sprint and how it will start working toward that goal. This is made visible in the sprint backlog.

Running a great sprint planning meeting requires a bit of discipline. The product owner must be prepared, combining the lessons from the previous sprint review, stakeholder feedback, and vision for the product, so they set the scene for the sprint. For transparency, the product backlog should be up-to-date and refined to provide clarity. Backlog refinement is an optional event in scrum, because some backlogs don’t need it. However, for most teams, it’s better to get the team together to review and refine the backlog prior to sprint planning.

Sprint planning should be constrained no more than two hours for each week of the sprint. So, for example, the sprint planning meeting for a two-week sprint would be no longer than four hours. This is called "timeboxing", or setting a maximum amount of time for the team to accomplish a task, in this case, planning the sprint. The scrum master is responsible for making sure the meeting happens the timebox is understood. If the team is happy before the timebox is finished, then the event is over. A timebox is a maximum time allowed; there is no minimum time allowed.

During sprint planning it is easy to get ‘bogged down’ in the work focusing on which task should come first, who should do it, and how long will it take. For complex work, the level of information you know at the start can be low, and much of it is based on assumptions. Scrum is an empirical process, meaning that you can’t plan upfront, but rather learn by doing, and then feed that information back into the process.

The sprint goal describes the objective of the sprint at a high level, but the backlog Items can also be written with an outcome in mind. User stories are one great way of describing the work from a customer point of view.  User stories, written like the one below, re-focus defects, issues, and improvements on the outcome the customer is seeking rather than the observed problem.

By adding clear, measurable results to the user story, the outcomes can be clearly measured, and you know when you are done. By getting as much up-front clarity as possible on the work the team is focusing on, everyone gets the transparency needed to get started on the work. For example, leaving things vague is much worse than describing something as a question to be answered during the sprint.

Sprint planning requires some level of estimation. The team needs to define what can or cannot be done in the sprint:  estimated effort vs capacity. Estimation is often confused with commitments. Estimates are by their very nature forecasts based on the knowledge at hand. Techniques such as story points or t-shirt sizing add value to the process by giving the team a different way of looking at the problem. They are not, however, magical tools that can find out the truth when there is none to be found. The more unknowns, the less likely the estimate will be correct.

Good estimation requires a trust-based environment where information is given freely, and assumptions are discussed in the pursuit of learning and improvement. If estimates are used in a negative, confrontational way after the work is completed, then it’s likely that future estimates will be either be much bigger to ensure they never are wrong again or the time taken to create them will be much longer as the team second guesses itself worrying about the implications of getting them wrong.

Focus on a 'just enough' plan

It is easy to get stuck in the details of sprint planning you forget that the focus of sprint planning is to build a ‘just enough’ plan for the next sprint. But be careful planning too upfront. That plan shouldn’t become a monkey for the team’s back, instead, it should focus the team on valuable outcomes, and allow guardrails for self-organization.

Prioritize goal-oriented planning

A good sprint plan motivates everyone by defining an outcome and a clear plan for success. Instead of building the most complete, “every minute of the sprint is accounted for” sprint plan, focus on the goal and build enough of a sprint backlog to get started.

Keep a flexible backlog

Ensure that the product backlog is ordered to allow the team to pick up work if they delivered on the sprint goal early.

Accept the empirical nature of scrum

Scrum is a process framework aimed at solving complex problems. Complex problems require an empirical process (learning by doing). Empirical processes are very hard to plan, so don’t kid yourself--you can’t build the perfect plan. Instead, focus on the outcomes and get going. It does not have to be hard, even if the problem you are solving is.

Ready to start? Learn how to use sprints in Jira