agile top banner

The Ultimate Guide to Sprint Planning

Read it in 16 Mins

Last updated on
06th May, 2021
18th Jul, 2020
The Ultimate Guide to Sprint Planning

The Scrum framework has been popular lately and several studies have provedthat the global share of Scrum is more than 50%. One of the reasons for the phenomenal success of Scrum lies in its ceremonies, one of its key pillars.  

Scrum has three critical components that create the structure or a skeleton and provides a way of working to the teams and individual, namely, roles, artifacts, and ceremonies. 

Scrum roles, artifacts and ceremonies

Scrum has four different ceremonies to support Agile software delivery where the Sprint starts with planning and ends with the retrospective. Let us quickly talk about the four ceremonies and then we will start with our topic of the day and deep dive more into Sprint planning. 

Daily Scrum 

The event is intended to bring together everyone in the scrum team and talk about what the accomplished last, what is the plan for today and is there any impediment. This event can be categorized under daily planning and collaborative team effort to attain the scrum goal. 

Sprint planning 

This event occurs at the start of the Sprint where the team together decides on the Sprint backlog and gains consensus on the sprint goal. They also talk about the estimation, capacity, risk, dependencies, and the timeline. This event is facilitated by the scrum master and occurs once in every Sprint. 

Sprint review 

This is the second last event in the print where the team showcases the entire deliverable they have been working throughout this print. This is the time when the stakeholders look at the finished product and provide their feedback. The event provides an effective platform for a collaborative approach with the client towards software delivery. 

Sprint retrospective 

This is one of my favorite events in Scrum, though the ceremony looks simple, if done correctly, it can yield tremendous results. It provides the team with a chance to pause and check which things are working, what is not, and how can they improve moving forward. 

Scrum ceremonies
Scrum ceremonies

Each of the ceremonies can be elaborated more as they are deep and dense. This article serves as an in-depthguide on Sprint planning for Scrum practitioners. 

The Sprint Planning meeting 

The What 

Sprint planning can be thought of as a ‘green flag’ that gives a go-ahead to the train called “Sprint”. The purpose of this meeting is to provide the sprint goal and ‘how’ that can be delivered. This is the first meeting that takes place in a Sprint where the scrum team comes together to create the Sprint backlog within a “time-box”, this time-box depends on the iteration length, if the iteration is of two weeks, the time-box can be up to four hours for a team of seven to nine people.  

During the Sprint planning meeting, the product owner describes the objective of the sprint and what product backlog items can be utilized to reach that objective. Consequently, the scrum team decides how to work on ‘how’ to get the goal achieved. 

The How 

The sprint planning meeting is divided into two parts, first part, constitutes discussion on the sprint backlog creation and the second part revolves around the capacity and estimation. The product owner must keep the product backlog stays in a healthy state, it is prioritized and has the right requirements for the team to work on. The team should also be aware of their capacity and velocity to make appropriate Sprint commitment. 

Spring Planning meeting agenda
Spring Planning meeting agenda

The Who 

The spring planning meeting is attended by the product owner, the development team, and the scrum master. All three roles are mandatory to run this meeting.  

The product owner defines the objective of the sprint and supports the development team with the product backlog. In turn, the development team talks about ‘how’ to deliver and the approach they could take. They can also inform the product owner if the requirement is not doable (at times, the requirements might not be technologically feasible, in such cases the team can discuss the same with the product owner). The Scrum Master takes up the facilitation of the event, they make sure the team sits with an effective ‘input’ and comes out with an efficient ‘output’. 

The Inputs 

The Product Backlog serves as the ‘Input’ for the Sprint Planning meeting. It provides the development team with the starting point as it contains the list of requirements for delivery. The Product Backlog is owned by the product owner and hence the responsibility of keeping it up-to-date falls within their purview. The team starts with the highest priority item in the list, clear doubts (if any) and add it up to the Sprint Backlog. To make proper sprint commitment, the team should know their capacity and velocity. 

The Outputs 

The sprint planning meeting intends to generate a sprint goal and backlog. The output also defines the ’how’ approach, which the team will take to reach its goal. The team must understand the value of this event, as this draws a path for sprint success. The Scrum Master can help the team and the product owner to come up with an effective plan through their facilitation skills.

Input and output of the Sprint Planning Meeting
Input and output of the Sprint Planning Meeting

How do we prepare for the sprint planning meeting? 

As with other events, the sprint planning meeting has a set agenda and timebox which the team must follow diligently. A healthy backlog is a key to efficacious sprint planning, which means, the Product Owner always must maintain and keep the backlog updated. The team needs to be aware of the available capacity and the targeted velocity this helps in coming up with the correct commitment during the Sprint planning session. 

What is a backlog? 

A backlog is a list of requirements from the client to create the desired product. It contains new features, enhancements, bugs, Infrastructure changes, or any architectural requirement. Any work that is related to a product should be in the backlog.  

Backlog items are placed in a prioritized list manner Every item in the backlog has an estimate it can either be a high-level estimate or the exact/close estimate, depending on where it falls in the list. Usually, the top few items in the bucket have more clarity, details, and close estimates as compared to the items down in the list. 

Determining velocity 

Velocity is unique for every team; no two teams can have the same velocity. Every organization has a different approach towards velocity, ideally, the teams should take an average of the last five sprints. The average formula works for the teams who have been in the system for long or they have spent at least eight to ten sprints as a team.  

Usually, velocity-based planning is done with mature teams who are aware of the product and they are good at process. With new teams, the ideal approach relies on the completed stories vs accepted stories ratio. 

Determining capacity 

Capacity is determined by available working hours in the sprint timeline which also takes into consideration, the leaves, any holidays, and contingency hours (if required). Capacity directly impacts the output as a team and helps them during Sprint commitment.  

Sprint Planning checklist 

While Agile development is more of a mindset than a methodology, checklists can help guidetheproduct owner, the development team, and the scrum master as they plan and execute sprints. 

Sprint planning preparation 

A few days out from the actual sprint planning meeting: 

  • Review product roadmap and vision.  
  • Ask team members to update boards and focus on moving tickets to done.  
  • Run sprint review and retrospective.  
  • Groom product backlog: Make sure every user story has a clear priority, is fully formed, and up to date with context and estimates.  
  • Choose sprint goal.  
  • Create a sprint backlog of enough user stories to fill two sprints. 

Sprint planning meeting 

  • Ensure your entire team is present for the meeting.  
  • Start video call for remote team members.  
  • If needed, clean up old board(s) with team by checking status of open tickets.  
  • Discuss spillovers: Should these be continued or dropped? Move any spill-over tasks into the right buckets.  
  • Set the stage with product and market updates.  
  • Define the sprint goal.  
  • Create a “new sprint”. Discuss the goal and team’s capacity:  
  • Is this realistic? If not, can the team lower the scope?  
  • Worst case scenario the product owner needs to come up with a new sprint goal. A few days out from the actual sprint planning meeting: 
  • Discuss proposed sprint backlog: Let the team pick user stories and tasks that match the sprint goal and capacity.  
  • Discuss the definition of “done”.  
  • Break down each user story into individual tasks: Make sure each task has as much information as possible.  
  • Ask whether the scope of work leaves time for unexpected issues.  
  • Ask if the scope of work leaves space to tackle bugs and technical debt.  
  • Move sprint backlog of decided-upon user stories and associated tasks into the sprint board.  
  • Get verbal confirmation from the team that they know what to do.  
  • Set up due dates and times for future scrum meetings.

Here is a quick checklist to help you plan the Sprint Plan. You can modify and adapt as necessary.

The outcome of the Sprint Planning meeting 

The planning meeting intends to come up with Sprint goal and sprint commitment which is in the form of Sprint backlog. This backlog contains a list of stories, bugs, enhancements, etc. as required by the product owner. The output of the Sprint planning meeting is also to define the approach, the task, and other activities required to achieve the Sprint goal.  

Everything that needs to be done is part of the Sprint backlog, by the end of Sprint planning meeting the team should have a solid plan with the ownership This output is further shared with the stakeholders, management and within the team which not only helps in being transparent but it also supports the team to stay focused. 

How to get Sprint Planning right 

Scrum focuses on time boxing and hence Sprint planning also requires control over the time limit for the event. As per the industry standards, a sprint of two weeks should be time-boxed for a maximum of 4 hours. The scrum master is responsible for making sure the team sticks to the timing and helps them in coming up with the plan. Spend planning can be an exhaustive ceremony where the team brainstorms, discusses the requirements and ownership.  

With great facilitation skills, the scrum master can ask the team to start with an item they know well and subsequently move forward. The team can utilize various estimation techniques to define a number or a story point for each requirement. They can use T-shirt sizing, poker planning, or any other technique they are comfortable with. For effective estimation, the team needs an environment that is transparent, trustworthy, and open to new ideas. This reminds us of the Scrum values and principles that form the foundation of the framework. 

Common reasons why Sprint Planning fails 

Multiple reasons can contribute to scrum planning failure. Let us look at some of the frequent cases: 

  • Uncooked backlog 

Most of the time the product backlog is not up to date and lacks prioritization. In such cases the team struggles in defining the Sprint goal, they face difficulties in defining the Sprint commitment due to lack of clarity and details. 

  • Unrealistic expectations 

Oftentimes teams are required to work on requirements that are not feasible, or the team faces some technological challenge. 

  • Over-commitment 

When the teams do not realize the capacity and their velocity and tend to over-commit, this leads to hurdles in delivery. 

  • Beyond Time-box 

Spending too much time in Sprint planning can also jeopardize the event, the team must follow the time-box, going over minute details is not required. Scrum is an empirical process, which means You do not have to plan everything upfront.   

Quick tips for success 

  • Set a Goal 

The Product Owner should come up with a sprint goal and share it with the development team. The goal helps the team and staying focused throughout the sprint, they can also use baby scrum meeting to check if they are on track with the goal. 

  • Healthy product backlog 

If the product backlog is in the Good shape, and has stories in order of priority, the team can start pulling from the top. they can even plan a pre-planning meeting, which is also known as backlog grooming who defines the upcoming sprint backlog. 

  • Valuable meeting measures 

Everyone in the team should have the sprint planning meeting invite and if required it should contain the link to video conferencing in-case of a distributed team. The team should have the data on capacity and velocity, and they understand estimations and prioritization. They can use different colored stickies to represent backlog items for example stories can be represented with green and bugs can be presented with red. As per the discipline, the team should follow timeboxing strictly, they can finish early but to go beyond the time is not recommended.  

Best practices in Sprint Planning 

To course a positive sprint, you need to be very prepared and have a solid understanding of what is practicable to shape with the team you have within the timebox. This is the reason why a sprint planning session is so vital for placing the foundation for an agile development project. Let us touch base on some best practices that the teams can adopt for the smooth running of the scrum event. 

  • Strategy for uncertainties 

During the sprint planning meeting, the team talks about capacity, velocity, and shapes their Sprint commitment around the confident items. Planning for uncertainties not only helps in contingency but it also reduces the upcoming risk that can pose an impediment for the team. 

  • Sprint skeleton 

Laying out the stories or Sprint items in the form of a map helps the team in getting a tentative idea around each deliverable. this also helps in defining the internal dependencies and the teams can better plan by moving them up and down. 

  • Building consensus 

It is important to get the team onboarded together as a single group for the sprint goal. They should understand the importance and the urgency of the deliverable and they are ready to take the ownership, this also requires supporting the teammates. 

  • Benefits of Sprint Planning 

A successful Sprint planning creates a smooth runway for the team to start their work. It provides clarity in terms of commitment, goals, timelines, and ownership. The output of the Sprint planning meeting sets an expectation with both the parties - the scrum team and the stakeholders - on what to expect by the end of the Sprint. It can be visualized as the team pulling a bucket of work from a big pile and focus on delivering that bucket with expected quality. 

Ready, set, sprint! 

“A goal without a plan is just a wish.” - French writer and pioneering aviator, Antoine de Saint-Exupéry 

Done in the right spirit, Sprint planning can do wonders in sprint delivery. All it requires is a focused approach, discipline, few best practices, and a collaborative approach towards a solution.  

If you have followed this guide, at the end of your sprint planning session you and your entire team should walk away with: 

  • An agreed-upon Sprint Goal and a clear definition of “done” 
  • Commitment to a realistic sprint backlog 
  • Understanding of the bug fixes and support work included in the backlog 
  • Detailed tasks for each user story with an estimation and acceptance criteria 
  • Due dates and scheduled scrum meetings 

Now, all you have to do is the work.

Ready to start or grow your Agile career?  

Check out our latest courses, learn the skills and get the personalized guidance you need. 


Deepti Sinha

Blog Author

Deepti is an Agile Coach by profession and Freelance Trainer with over 11 years of industry experience working primarily with healthcare & finance clients in delivering business. She has played a wide variety of roles in the graph of her career, whether it be, management, operations or quality. She likes reading fiction, management and loves to write her experiences. Her colleagues mostly describe her as very detail oriented person with a knack of creativity and imagination. And yes, she loves feedback more than her coffee!!