Sprint is the heartbeat of Scrum, and all work in Scrum is done during Sprints. It is a time-boxed activity that usually takes 1-4 weeks long, and it starts with a Sprint Planning meeting and ends with a Sprint review and retrospective meeting. Teams develop increments of functionality during Sprints. Scrum is a process framework for new product development created by Jeff Sutherland and KEN SCHWABER. The word "Scrum" is taken from the Rugby game, wherein the team huddle is called Scrum.
Since new product development is complex, Scrum offers an iterative and incremental development approach. Scrum has three roles, namely, Scrum master, Product owner and the Development team of size 3-9. All three roles are empowered to do their job and have no authority over each other. However, they work as self-organizing teams to deliver a product with complimenting skills.
In this article, you will learn what Sprint Planning in agile is, why it is important, how and when it should be done, and more. You will get a high-level view of Sprint Planning, understand the core concepts involved, Sprint Capacity Planning, Agile certifications / Agile Training online and learn how to bring and implement Sprint Planning to life in your Agile projects so that you can get the maximum benefit from this technique.
What is Sprint Planning?
It is a Scrum ceremony and is used to plan the work of sprint. The Sprint Planning meeting is the first event and occurs on the first day of a new sprint. The product owner collaborates to help the team select items (requirements) from the product backlog for the upcoming Sprint. The Scrum master facilitates the time-boxed Sprint Planning in Scrum.
The team and Product owner primarily focus on achieving the below goals:
- Determine what team can deliver in this sprint
- Plan how the team will achieve the delivery. Focus on highest priority discussions, and they have a sense of urgency
Prioritized definition of the ready product backlog, the latest product increment, the capacity of the DEV sprint during the sprint, team velocity / past performance and DONE definition are the input criteria of the Sprint Planning in agile.
Defining sprint goals and defining sprint backlog with a shared understanding are the output criteria of Sprint Planning in agile.
How To Prepare for Sprint Planning Meeting?
Below are some important pointers for Sprint Planning in Scrum:
- Examine team availability.
- Establish speed for your team.
- Plan your Sprint Planning meeting.
- Start with the big picture.
- Present new updates, feedback, and issues.
- Confirm team velocity and capacity.
- Go over backlog items.
- Determine task ownership.
- Velocity-driven Sprint Planning.
- Sprint Planning poker
- Scrum Master Sprint Planning
- Sprint Planning meeting agenda.
Who Is Involved in Sprint Planning?
Below are the required invitees for the Sprint Planning session:
- ScrumMaster (facilitator)
- Product Owner (sets the goal and priority)
- Development Team (plans the work to be done and determines how much it will take)
- Key Stakeholders (Client/business) and/or other subject matter experts who can provide insight on user stories being considered.
Where Does Sprint Planning Take Place?
Sprint Planning can be done virtually using MS team meeting, Zoom, Webex etc., with Sprint Planning meeting agenda if the teams are globally distributed/collocated at different locations. In an office environment, 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 update any information radiators. Always organize Sprint Planning in Scrum with Sprint Planning agenda and Sprint Planning poker.
How Is Sprint Planning Structured?
Here is a general structure for conducting a sprint planning session:
- Select the characteristics of Sprint Planning in Scrum,
- Ensure velocity-driven Sprint Planning, Sprint Planning poker, Sprint Capacity Planning, and Jira Sprint Planning with Sprint Planning meeting agenda.
- Examine team availability and Sprint Planning.
- The Product owner shares the product vision with the team.
- The DEV team decides what can be achieved in the Sprint, DEV team collaborates to choose a Sprint goal and understand the purpose and impact of the work.
- Confirm estimated story points for all items on the backlog (or, at minimum, in the next sprint).
- Stick to Sprint Planning meeting duration, the role of Scrum master in Sprint Planning, velocity-driven Sprint Planning and Sprint Planning template in Sprint Planning session.
- The DEV team decides HOW the chosen work will get done.
- Focus on the highest priority discussions, and the team has a sense of urgency.
- It is OK if a team doesn’t complete every sprint backlog item. As long as they are finishing those, they do start.
- Confirm team velocity and capacity.
- Go over backlog items.
- Determine task ownership.
Sprint Planning Checklist
Source
We need to have some checkpoints for the important parameters so that we can effectively measure the Sprint Planning meeting outcome.
Pre-Sprint Planning Meeting
Let us see some main checkpoints of Sprint Planning in Agile:
- Clear up what is in the DOING / Sprint backlog.
- Do the movement of any items that might need to be updated.
Sprint Planning Checklist
Check some main checkpoints of Sprint Planning in Scrum:
- Capacity - Who is taking time off this Sprint? Does anyone need space to work on PD items (learn, attend, grow)?
- Sprint Goal: Review the goal and allow for questions and clarification.
- If using velocity, review previous velocity and estimated velocity.
- Include any action items that came from the previous retrospective.
- Do we need to make space to clean up bugs? If so, what is the priority (compared to other work)?
- What could you work on OR do you want to learn about things related to the sprint goal?
- Refine and Detail. Take approx. 15 minutes adding acceptance criteria and tasks / checklist items including description, order, and size.
- Put items over from the product backlog, one at a time asking about capacity, clarifying tasks, who is doing what, and splitting cards if they seem too big.
- Dependency Check - Is anyone needed from another team? If so, send them a message and see if they can help.
- Is there anything else which needs to be pulled in?
- Double check capacity. If you are using velocity techniques to forecast your sprint, pause as you get close to your team's reasonable velocity to ask. "Have we committed too much for this sprint?"
- Continue for those that still have space.
- Make sure that the next work that the team has pulled aligns with the sprint goal, allowing the team to focus on one goal.
Post- Sprint Planning
Let us take you through the main checkpoint of Sprint Planning in Scrum:
- Ensure there is time scheduled / planned for Sprint review preparation work.
- Inspect, adapt, improve and sustain the above checklist based on client / organization / team requirement as applicable.
Enroll in KnowledgeHut’s Agile training online to boost your knowledge and advance your career in Agile Management. With this certification, you can apply for job roles such as Product Managers, Project Managers, Scrum Masters, Business Analysts, release train engineers, etc.
How Long Should a Sprint Planning Session Take?
As per Scrum standard, each part is timeboxed to two hours per week of sprint. Sprint Planning duration is timeboxed to 8 hours for one month sprint. For shorter sprints, the timebox is shorter.
Remember, a timebox is a maximum amount of time, not a minimum or suggested amount of time. Many experienced Scrum teams regularly spend far less than Sprint Planning timebox.
What is a Valuable and Efficient Product Development Session?
Ensure Sprint Planning happens on the first day of the sprint, having a timebox of 8 hours for 4 weeks Sprint. Generally, the Product Owner (PO), SCRUM Master (SM) and the team attend it.
But a high-level recommendation is to involve business/customer in Sprint Planning so that the shared common Sprint goal and Sprint backlog are achieved by the end of Sprint Planning in sync with all key stakeholders, and thus we can avoid unnecessary product development silos.
Make sure the Product Owner is in sync with the business/customer. The Team can decide HOW they will complete the work that they are committing to for Sprint. In practical terms, the team looks at each of the Product Backlog Items (refined PBI, usually written as User Stories) and identifies all of the tasks that need to be completed for the PBI to be considered ready for production).
Stick to Sprint Planning meeting duration, role of Scrum master in Sprint Planning, velocity driven Sprint Planning and Sprint Planning template in Sprint Plaping session.
Applying a Two-part Solution
If you are in your early days of Agile adoption and have one or more symptoms of a poor backlog, try a two-part approach that can push the team in the right direction. The goal is to have the business and IT team work together and show agility to beat the competition and provide the best solution to customers.
Part 1: Set Expectations
The product owner is the voice of the customer and is closely tied to the delivery team. So, set the right expectation with the product owner. Ask the product owner to apply a priority order to the backlog, with a clear definition of ready and defined stories and acceptance criteria. Developers and business stakeholders should be able to understand the criteria easily, and the product owner should provide proper insights whenever required.
The product owner should also define which story is a must for the feature and which story should be considered a nice-to-have. When these stories have been identified, it is easy for the development team to start working on the backlog.
Part 2: Schedule Regular Backlog Grooming Sessions
It is typical for a new Agile team to have a product owner who struggles to define the priority order of a backlog. To solve this problem, run a common backlog grooming meeting in which the product owner, product manager, and someone from the technical team meet regularly (weekly is recommended).
This team should discuss the current business opportunities and potential IT solutions, and should rearrange the backlog according to the current business priority. This meeting should provide a solid foundation for the backlog grooming and enable the product owner to provide clear directions to the Scrum team.
The meeting should not only focus on the current and next sprint but also continuously work towards the future direction of the product. The product backlog sheds light on the path of product development.
The outcome of Sprint Planning Meeting
The outcome of a sprint planning meeting typically includes the following:
- Scrum team feels comfortable with the goal and has identified user stories that support the goal.
- The product owner confirms that the sprint plan aligns with the vision, roadmap and release goal.
- The Sprint plan is completely captured on the team’s task board or agile tool.
- The Burndown chart is set up.
- Each DEV team member knows exactly what they will work on when they leave the meeting.
How to Get Sprint Planning Right?
Correct Sprint Planning can be done keeping the below points in mind:
- Determine backlog priority and order by business value and risk.
- Definition of DONE- Each item in the team's definition of DONE should be accounted for explicitly as individual tasks of each user story.
- Only development team members estimate user stories and tasks.
- The product owner stays actively engaged and provides immediate clarification on the user stories as needed.
- The product owner has the final authority / say on which user stories make it into the sprint based on priority and velocity.
- Velocity is an input for the team to determine the number of points that should be accepted in the sprint. Teams should always be stretching to accomplish more in each sprint. It is OK if a team does not complete every sprint backlog item as long as they are finishing those that they start.
- Sprint Planning meetings should not last longer than one hour each week. Ensure every stakeholder attends the Sprint meeting.
- Ensure that the sprint is planned with proper business input and priority.
- Be sure that Sprint Planning happens on the first day of the sprint, having a timebox of 8 hours for 4 weeks sprint.
- Ensure that the Product Owner (PO), SCRUM Master (SM) and team attend it.
- Make sure that both shared common sprint goals and sprint backlog are achieved by the end of Sprint Planning in sync with all key stakeholders.
- Ensure the Product owner is in sync with the business/customer and can decide WHAT can be delivered in the shippable product increment resulting from the upcoming sprint.
- Make sure the team can decide HOW they will complete the work that they are committing to for this sprint.
- Select the characteristics of Sprint Planning in Scrum, ensure velocity-driven Sprint Planning, Sprint Planning poker, Sprint Capacity Planning, and Jira Sprint Planning with Sprint Planning meeting agenda. Stick to Sprint Planning meeting duration, the role of Scrum master in Sprint Planning, velocity-driven Sprint Planning and Sprint Planning template in Sprint Planning session.
Common Reasons Why Sprint Planning Fails
Reason 1 - Poorly planned Sprint Planning sessions without business input can lead to failure. This failure is often caused by inadequate backlog grooming by the Product Owner. When the Product Owner struggles to provide clear direction, it negatively affects the team's results and the overall profitability of the organization. A well-defined product backlog is crucial for successful product development. If the backlog is not properly defined, the development team will struggle to deliver meaningful objectives that drive business value and impact profitability.
Reason 2 - It is a driver for successful product development, and reaching the organization's goal is impossible if this direction is missing. The product backlog also plays a critical role in engaging the Scrum team. If the product owner can effectively articulate the business challenges to the Scrum team, they can point the Scrum team in a positive direction. However, if the business objectives are uncertain or there is no rationale behind some of them, the Scrum team is unmotivated because it is unable to understand what value they are providing and how they will impact customers.
Reason 3 - The repercussions of a poor backlog are high, and an organization cannot afford this situation for too long. As soon as any symptoms occur, it must correct the process. The product backlog should be the center of development, and we must always keep it current and meaningful. Product owners never attend Sprint Planning meetings. It causes failure of the Sprint Planning session.
Reason 4 - Sprint Planning meeting fails due to poor Planning. When a Scrum team struggles to define a solid plan during the Sprint Planning session and the product owner is unable to provide clear direction, this is the first indication that the team has a serious problem. In this case, the result of the planning meeting will be either no planning or objectives that do not have a clear value defined. I call this impulsive Sprint Planning. The sprint was planned without any business inputs, and it was held only for namesake. It is not a winning situation for the organization because it will not get a good return on investment. It will not only affect spending but also the timing and opportunity to beat the competition.
Reason 5 - Sprint Planning must not happen on the first day of a new sprint as it lacks sufficient details, leading to failure. It is crucial for the Agile team to gather the necessary information during Sprint Planning to ensure they can deliver on their commitments and maintain credibility. Ideally, someone from the IT team should be involved in backlog grooming to capture the required level of detail. If IT representation is lacking, the tech lead or architect can collaborate with the product owner prior to Sprint Planning to address this issue.
Reason 6 - The product Owner never considers the Prioritized definition of ready product backlog in the Sprint Planning meetings. It causes failure of the Sprint Planning session.
Reason 7 - Sprint Planning fails due to more than 20% Churn in Objectives. If you are running two-week sprints and your business objectives are constantly shuffling, it indicates that your backlog is not solid. Your product owner has to work hard to lock down the objectives. Some degree of churn is expected, but if it is more than 20%, the product owner deserves feedback. Showing agility to the business is important, but if this churn is frequent, it will curtail it. It is okay to have churn to support the business, but course correction is required if it is the result of poor backlog planning. All types of changes have a cost associated with them. The product owner should be able to recognize this pain and work toward solidifying the backlog grooming process.
Reason 8 - Scrum Master and DEV team never consider the team velocity and DONE definition in Sprint Planning meetings. It causes failure of Sprint Planning.
Reason 9 - Sprint Planning in Agile can fail if customer feedback is ignored during backlog grooming. Involving customers in the process is crucial to ensure the right product is delivered and avoid wasted resources. By listening to customer input and involving them early on, the team can make course corrections and keep customers engaged in the development process.
Reason 10 - Sprint Planning in Scrum can fail due to running out of funds. It's important to prioritize requirements and distinguish between must-haves and nice-to-haves. If a team spends too much time on nice-to-have features and runs out of money for essential ones, it's a problem. The team should focus on delivering the must-haves first and then consider the nice-to-haves if time and budget allow. If your team consistently runs out of funds, it indicates a lack of proper direction. Coach the product owner on prioritization and have open dialogues to set expectations.
Unleash your team's potential with our project management corporate training. Enhance productivity and attain unprecedented success.
Best Practices in Sprint Planning
Scrum meetings are all Inspect and Adapt opportunities. Discuss and list "Dos and Don’ts" for each meeting and leverage the best practices & effective questioning techniques in the Sprint Planning session.
Best Practices 1
| DOs | DON’Ts |
|---|
| Product Owner attends the Sprint Planning meeting. | Product Owner never attends the Sprint Planning meeting. |
| Sprint Planning session occurs on the first day of a new sprint. | Sprint Planning session never occurs on the first day of a new sprint. |
| Product Owner considers the Prioritized definition of ready product backlog in Sprint Planning in agile. | Product Owner never considers the Prioritized definition of ready product backlog in Sprint Planning in agile. |
| Scrum Master and DEV teams consider the team velocity and DONE definition in Sprint Planning in Scrum. | Scrum Master and DEV team never consider the team velocity and DONE definition in Sprint Planning in Scrum. |
| Sprint is planned with proper business input, and it is held to deliver business value. | Sprint is planned without any business inputs, and is held only for namesake. |
Sprint Goal & User Stories - Best Practices 2
Questions Product Owner & DEV Team should ask themselves while the team plans the sprint goal and user stories in the Sprint Planning Meeting
As the team plans the sprint goal and user stories, use as many of the following questions as needed to guide the team through the planning process. Not all questions will apply to every team and/or user story.
Product Owner reviews current situation (product vision, roadmap, release plan or story map, etc.) as needed and how will we know when we’ve accomplished it?
Product Owner reviews sprint Goal, what is it and how will we know when we’ve accomplished it?
DEV Team reviews sprint capacity.
Sprint Capacity: Based on the team’s velocity and experience, how much can we take on this sprint?
Story Points: What is our established velocity? Use this as an input to determine how many story points should be accepted.
The team should always be looking to stretch beyond what they’ve done in the past.
Hours: Has the team established what its effective day (actual working hours/day) is? If the team uses tasks to break down user stories, how many hours are available for this sprint?
Are all maintenance and overhead candidates estimated with story points so that they can be planned within capacity appropriately?
The Product Owner & DEV Team review candidate backlog items for the sprint and check the points below:
- Does each candidate user story support the sprint goal?
- Is each user story ready, according to the definition of ready? If not, can we quickly make it ready now?
- Are all clear about the desired outcome?
- Is the sum of all story points accepted for the sprint greater than the amount agreed upon by the team? If so, the Product Owner needs to decide which of the lower priority items to take out.
- Most teams will do 6-10 user stories per sprint.
- User stories should be 8 points or less to be accepted into a sprint.
Sprint Backlog - Best Practices 3
Questions Product Owner & DEV Team should ask themselves while the team plans for Sprint backlog grooming in the Sprint Planning Meeting
As the team plans the work to be done for each user story in the sprint and plan for sprint backlog grooming, use as many of the following questions as needed to guide the team through planning process. Not all questions will apply to every team and/or user story.
DEV team & Product owner need to check what is the next highest priority item to deliver this sprint? Plan that one next.
DEV team & Product owner need to check what else do we need to understand about this story? Is the deliverable clear? Do the acceptable criteria adequately define the requirements of the story, and are they clear?
DEV team needs to check do we understand our implementation approach for this story? Do we need to have a quick whiteboard design discussion now, or perhaps schedule one as part of the story's work?
DEV team needs to check what our tactical approach is for delivering this story? Can we list out the things we need to do?
The things we need to do (tasks) can be captured on our task board or in our agile tool.
DEV team needs to check what our estimated effort is for the work needed to deliver this story?
Work (tasks) can be estimated in the number of work hours it would take to complete each task. Ideally, tasks should be able to be accomplished in a day.
The DEV team needs to check if we are considering all the work that is needed to fully complete and deliver the story (get it to "DONE")?
We should check to make sure we include everything from our team's "Definition of Done".
DEV team needs to check is this user story, and its tasks, conductive to swarming so that one team member can take on one task at a time?
DEV team & Product owner need to check having now planned the work to be done, is it still sized appropriately?
Sprint Backlog Verification - Best Practices 4
Questions Product Owner & DEV Team should ask themselves while the team plans for Sprint backlog verification in the Sprint Planning Meeting
Before finalizing the sprint backlog, review the following general guidelines and make adjustments as needed.
DEV team needs to check for conflicts. Can the set of stories in our sprint backlog be accomplished together in this sprint?
Consider if there will be conflicts and how to resolve them. Adjust as needed.
DEV team needs to check for "Definition of Done". Will we be able to deliver a fully "Done" increment of our product at the end of this sprint? We should check to make sure we are including everything from our team's definition of done.
DEV team & Product owner need to check the missing backlog items. Is the team aware of any work that needs to be done that is not included in the sprint backlog, including maintenance and overhead items, spikes, release planning activities, or any other activity that needs to be accomplished this sprint?
If so, add them to the backlog, estimate them, re-calculate total points, and adjust sprint backlog as needed to fall within the number of points agreed by the team.
The DEV team needs to check if there are any other risks or circumstances that we need to be aware of during this sprint. If so, have we included resolving these things in our sprint plan?
DEV team needs to check can we commit to our sprint plan? Can we describe how we intend to deliver the sprint? "Commitment" means we agree our plan seems achievable, and we agree to work to our plan.
DEV team & Product owner need to check the task board & burndown setup. Has our sprint plan been completely captured on our task board or in our agile tool? Are we ready to begin tracking our sprint, including producing sprint burndowns or other metrics we use?
Close - Best Practices 5
Questions Product Owner & DEV Team should ask themselves while the team plans to close the Sprint backlog verification in the Sprint Planning Meeting
As the team plans to close sprint backlog verification, use as many of the following questions as needed to guide the team through the planning process. Not all questions will apply to every team and/or user story.
DEV team needs to check what will each team member start working on when they walk out of this meeting?
Have each team member select one task to begin working on.
Update your task board or agile tool to reflect what everyone is starting to work on.
Best Practices 6
Sprint Planning Meeting and Backlog
Scrum master needs to check if issues came up during the meeting that require follow up outside of the team meeting (such as organizational impediments, items not related to the sprint, etc.), make sure they are documented and assigned for follow up as needed.
If product development is using the Scrum framework, user stories are discussed, and the team learns more about them during Sprint Planning. This discussion between the team and product owner is important as the team learns more about customer expectations through it. Based on this discussion, new user stories are identified, and details are added to them and previous user stories initially created by the product owner.
Based on the facts that have been uncovered in the Sprint Planning meeting, the team estimates the user stories again. It takes up high-priority user stories for the sprint that they can complete and deliver value to customer. If user stories cannot be taken up in Sprint, they are sent back to the product backlog to be prioritized in the next Sprint.
Backlog is refined at different stages by different people based on their area of expertise, the exposure to products, and the customers they have. A common backlog keeps the team and organization focused on a common goal. Let us summarize the different types of backlogs and stakeholders responsible for them:
The key element of building an agile contract is a mindset. The following table can help understand the backlog refinement expected from different stakeholders:
| Backlog Type | Content | Stakeholder Responsible |
|---|
| Portfolio backlog | Initiatives | Executives |
| Program backlog | Features | Product management |
| Product backlog | User stories | Product owner |
Backlogs are primarily focused on creating customer value. Some backlog items are added to experiments and get more clarity on features or the approach to be taken for development. The backlog also contains some content that will help the team become more efficient (technical debt-related action items from retrospective meeting etc.).
Estimation happens at two levels:
In backlog refinement, relative estimation in terms of story points or t-shirt sizes.
In Sprint Planning, absolute estimation takes place in terms of person hours or ideal days. The focus is on using the available capacity of team members in a sprint.
Conclusion
Anyone who has created best practices in Sprint Planning knows that this takes time and effort, and the best results come with experience. They allow teams to see the bigger picture, keeping the user at the core of all development progress. When done the right way, Sprint Planning promotes meaningful collaboration, enables quicker feedback and faster deliveries, and results in creating high-quality product features that most suit customer needs. Check KnowledgeHut Agile Management Courses to stay updated on the latest knowledge of Scrum.
