What is sprint planning?
Sprint planning is an event in scrum that kicks off the sprint. The purpose of sprint planning is to define what can be delivered in the sprint and how that work will be achieved. Sprint planning is done in collaboration with the whole scrum team.
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 session 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.
- The What – 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.
- The How – 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.
- The Who – You cannot do sprint planning 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 cannot deliver that goal. If either is missing from this event it makes planning the sprint almost impossible.
- 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.
- The Outputs – The most important outcome for the sprint planning meeting is that the team can describe the goal of the sprint and how they will start working toward that goal. This is made visible in the sprint backlog.
Prep for sprint planning meeting
Running a great sprint planning event requires a bit of discipline. The product owner must be prepared, combining the lessons from the previous sprint review, stakeholder feedback, and their 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.
PRO TIP:
If you have a two-week sprint, run a backlog refinement meeting in the middle of the sprint. It’s great for the team to step back from the sprint and look at what’s next. Not only does it help prepare for sprint planning, but also can give a different perspective for the current work.
Setting a time limit for 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 two 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.
Focus on the outcomes not the work
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.
PRO TIP:
Not knowing something is different from being vague. Don’t ignore the unknowns, they are the reality of doing difficult work. But don’t hide them by using vague words. Instead, be clear when you don’t know something and frame the work in terms of gaining an understanding.
Estimates are required but don’t pretend you know more than you do
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.
PRO TIP
Explore using different estimation techniques such as t-shirt sizing or story points. Different techniques might provide different views of the problem.
Sprint planning best practices
It is easy to get so bogged down 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. 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. A good sprint plan motivates everyone by defining an outcome and a clear plan for success. But be careful planning too upfront. 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. Next, ensure that the product backlog is ordered to allow the team to pick up work if they delivered on the sprint goal early.
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.