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. The What – The product owner describes the objective(or goal) of the sprint and what backlog items contribute to that goal.
- What is sprint planning?
- The What ,How , Who?
- Prep for sprint planning meeting
- Setting a time limit for sprint planning
- Estimates are required but don’t pretend you know more than you do
- Sprint planning best practises
- Who is involved in Sprint Planning
- Where, when does Sprint Planning take place?
- How is Sprint Planning Structured?
- Conclusion
- Sprint planning is an event in scrum that starts the sprint. The purpose of sprint planning is to define what can be delivered in a sprint and how that task will be achieved. Sprint planning is done in collaboration with the entire scrum team.
- In scrum, a sprint is a set period of time where all the work is done. However, before you can leap into action, you must set up a sprint. You need to decide how long the time box is going to last, the sprint goal, and where you are going to start. The sprint planning session kicks off the sprint by setting the agenda and focus. If done properly, it also creates an environment where the team is inspired, challenged and can succeed. Poor sprint plans can derail a team by setting unrealistic expectations.
What is sprint planning?
The What ,How , Who?
What – The Product Owner describes the purpose (or goals) 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 it happen.
How – The development team plans the work needed to meet the sprint goal. Ultimately, the resulting sprint planning is an interaction between the Development Team and the Product Owner, based on value and effort.
The Who – You can’t do sprint planning without a Product Owner or Development Team. The Product Owner defines the goal based on the value they want. The development team needs to understand how they may or may not meet that goal. If one is missing from the event it makes it almost impossible to plan the sprint.
Input – A great starting point for sprint planning 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 increments and think about the potential.
Output – The most important outcome for a sprint planning meeting is that the team can describe the goal of the sprint and how it will begin working toward that goal. It appears in the Sprint Backlog.
- Running a great sprint planning program requires a little discipline. The product owner must be prepared, combining lessons from the previous sprint review, stakeholder feedback, and vision for the product, so that they can set the scene for the sprint. For transparency, the product backlog must be up-to-date and refined to provide clarity. Backlog refinement is an optional event in Scrum, as some backlogs do not require it. However, for most teams, it is better to bring the team together to review and refine the backlog prior to sprint planning.
- 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 see what’s next. This not only helps to prepare for sprint planning, but can also give a different approach to the current work.
Prep for sprint planning meeting:
Setting a time limit for sprint planning:
Sprint planning should be constrained to no more than two hours for each week of the sprint. So, for example, a sprint planning meeting for a two-week sprint would not exceed two hours. This is called “timeboxing”, or setting the maximum amount of time for a team to complete a task, in this case, sprint planning. The Scrum Master is responsible for ensuring that meetings take place and that the timebox is understood. If the team is happy before the timebox expires, the event is over. A timebox is the maximum allowed time; No minimum time allowed.
Focus on the results, not the work
During sprint planning it is easy to get ‘stuck’ in work about what should come first, which should be done and how long it will take. For a complex task, the level of information you may initially know is low, and much of it is based on assumptions. Scrum is an empirical process, which means you can’t plan in advance, but learn by doing, and then feed that information back into the process.
The sprint goal describes the purpose of the sprint at a high level, but backlog items can also be written with the outcome in mind. User stories are a great way to describe a task from the customer’s point of view. User stories, written like the one below, re-focus on defects, issues and fixes as a result of customer demand rather than the problem seen.
A graphic showing how a user story is written
By adding clear, measurable results to a user story, results can be clearly measured, and you know when you’re done. By getting as much clarity as possible on the work the team is focusing on, everyone gets the transparency they need to start work. For example, leaving things unclear 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 a sprint: estimated effort vs. Estimates are often confused with commitments. Estimates are by their very nature predictions based on the knowledge at hand. Techniques like story points or t-shirt sizing add value to the process by giving the team a different way of looking at the problem. However, they are not magical tools that can find out the truth when no one is to be found. The more unknowns there are, the less likely the conjecture is to be correct.
- Good inference requires a belief-based environment where information is freely given, and assumptions are discussed in the pursuit of learning and improvement. If estimates are used in a negative, confrontational way after the task is completed, it is likely that future estimates will either be too high to ensure they are never wrong again or The time it took to make them would be too long for the team to second-guess they worry about the implications of getting it wrong.
Estimates are required but don’t pretend you know more than you do:
Sprint planning best practises:
It’s easy to get so caught up in the details of sprint planning that you forget that the focus of sprint planning is to plan ‘just enough’ for the next sprint. The plan should not become a monkey for the team’s back; instead, the team should focus on valuable results, and allow for handrails for self-organisation. A good sprint plan motivates everyone by defining an outcome and a clear plan for success. But be careful planning in advance. Instead of building the most complete, “every minute of a sprint counts” sprint planning, focus on the goal and build up enough sprint backlog to get started. Next, make sure the Product Backlog is ordered to allow the team to take work if they deliver on the sprint goal early.
Scrum is a process framework aimed at solving complex problems. Complex problems require an empirical process (learning by doing). Planning empirical processes is very difficult, so don’t underestimate yourself–you can’t plan right. Instead, focus on the results and move on. It doesn’t have to be hard, even if the problem you’re solving is one.
Who is involved in Sprint Planning:
Sprint planning usually involves the entire team.
A Product Owner identifies candidate Product Backlog items and their relative priorities, as well as proposes a Sprint Goal.
A Scrum Master or Coach typically facilitates Sprint Planning to ensure that discussions are effective and there is agreement to the Sprint Goal and that the Sprint Backlog includes appropriate Product Backlog items.
Team members determine how many Product Backlog items they anticipate they will be able to complete and determine how they will deliver those Product Backlog items.
- The event should be followed by a sprint review and retrospective from the previous sprint so that any output from those discussions can be considered when planning a new sprint.
- It doesn’t happen immediately after those two other events. You’ll find it best to put a higher priority on scheduling the sprint planning when the entire team is available.
- You may find that it is best to have consistent time for sprint planning so that your team can keep that time slot clear of other engagements.
Where, when does Sprint Planning take place?
A good location for sprint planning is the team room so that you have access to all the information about your product backlog and you can reference and update any information radiators you may use.
If your team is distributed, sprint planning represents a good opportunity to gather everyone together so that your planning discussion can be more effective and reinforce the person-to-person connection within the team.
Sprint planning takes place on the first day of a new sprint.
- What is the goal of this sprint? Use this as a decision filter to determine which product backlog items to include in the sprint.
- Which Product Backlog Items Are Prepared and Contribute to the Sprint Goal?
- Who is available for this sprint? Identify holidays, vacations, other activities that affect everyone’s availability during the sprint.
- What is the capacity of the team based on everyone’s availability.
- What items the team will include in the Sprint Backlog based on the sprint goal and the team’s capability.
- How confident is the team that they will be able to meet the sprint goal.
- Enables the team to agree on a sprint goal and commitment.
- Enables task search, sign up, prioritisation and estimation
- Builds the platform to communicate dependencies and identifies a team’s ability to set and commit to an achievable sprint goal.
How is Sprint Planning Structured?
Sprint planning is generally divided into two parts:
Part 1 – Scope
The team selects which items from a priority list of finished product backlog items (usually expressed as user stories) they estimate they will be able to complete during the sprint.
Here is a sample agenda for the first part of Sprint Planning:
Part 2 – Planning
The team discusses in more detail how they will deliver selected product backlog items. This may include (but is not) identifying tasks for Product Backlog items, whether there are any dependencies between items, and signing up for initial Product Backlog items on which each team member worked.
Benefits of Sprint Planning Meeting:
- A sprint planning meeting is held prior to the start of the sprint. The purpose of this meeting is to determine the sprint plan and set sprint goals.
- Sprint planning includes agreeing on the number of backlog items in the sprint that is the responsibility of the development team as well as defining goals for the current sprint and sprint backlog.
- During the Sprint Planning meeting, the Product Owner describes the top priority features to the entire team. Then they will discuss what stories the team will do in that sprint. The entire team should participate in the meeting. If additional expertise is required on specific backlog items, stakeholders may also be invited. The team may also include refinement sessions.
Conclusion: