How to run a sprint planning meeting w sample agenda

That will let team members know what to work on next if it happens they deliver on the sprint goals early. To kick off sprint planning, introduce any new members who might have joined since the previous sprint and state the purpose of the meeting. If you have natural language processing any ground rules around sprint planning, you can also review these briefly or include them on the agenda for all to see. To discuss the proposed velocity for this sprint, the story points and the team’s velocity in previous sprints should be considered.

Doing this in the group setting is helpful as it may answer questions that other team members had (or didn’t think of yet). If you don’t have the extra time to spare in your meeting, you can also launch a post-meeting survey, including a spot for a Q&A session following the sprint planning meeting. Being the first meeting before the beginning of a new sprint, it sets the scene for the upcoming week—if not more. The ultimate goal of the sprint planning meeting is for the development team to commit to completing a significant chunk of work during the coming sprint. The sprint planning meeting is a formal meeting during which the development team identifies and estimates the work for the next sprint.

Included In

The development team gets to know who will handle which task in the product backlog and how efficiently they perform the task. In this guide, we’ll go over the key elements of a sprint planning meeting agenda and provide tips for making the most of this important event. In this post, we explored the basic building blocks for an efficient sprint planning meeting agenda. In addition, we considered what happens during the sprint planning meeting. Having a successful sprint planning meeting is crucial to completing meaningful work and developing your product.

The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning. As described in the Scrum Guide, Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint.

Sprint Planning Meeting

Items that were not completed in previous sprints might be moved to the backlog. The backlog also includes new items that surfaced during previous sprints. The scrum team will review the backlog to check out what’s remaining to work on and decide on what should be done next to keep the project on track. A good guideline is for the product owner to come to the sprint planning meeting prepared to talk about two sprint’s worth of product backlog items. New stories might have been added to the product backlog as a result of sprint review feedback. Different stories might exist on the product backlog after those stories were split.

Smaller tasks will help the team evaluate the activities they need to do to complete their stories. While L and XL stories can stay in your sprint backlog, it’s advised to break as many up as possible. As you do your estimations, it’s best to factor those distractions in. They will happen, whether we like it or not, so the real number of hours you’ll get for the project might drop down to something like 250 hours.

What Are the Outputs of Sprint Planning?

Definition of done is a list of requirements that should be all ticked before the product backlog item can be considered complete. It’s not necessary to do that and some project teams have the DOD the same throughout the project. However, if in your case you feel like it’s necessary, it should be added to the agenda. The recommended length of the sprint planning meeting is 1-2 hours per sprint week, so a 2-week sprint would mean an up to 4-hour planning session.

• That will let team members know what to work on next if it happens they deliver on the sprint goals early.
• Scroll to the end to see a sprint planning meeting agenda template you can use as a cheat sheet when conducting your own sprint planning ceremony.
• Shorter sprints will have even shorter planning times, such as one to two hours of sprint planning for a two-week sprint.
• Use our sprint planning meeting template to provide structure and set expectations for your team.
• This resulting plan is created by the collaborative work of the entire Scrum Team.

It’s a good rule of thumb to try and fit your sprint planning into a maximum of two hours per sprint week. Marketing and sales may occasionally jump into the conversation to share insights that will assist the development team with building the feature. In the sprint planning meeting, you’ll comb through the product backlog, decide on action items, define a sprint goal, and dive into multiple user stories. Team capacity is the measure of how many story points or product backlog items (scrum parlance for “tasks”) your team can complete during a sprint under normal circumstances. Capacity is calculated as the number of team members multiplied by how many hours a day they can work productively. Having the completed user stories from your product teams in advance allows you to prepare requirements as it relates to the software development team.

Who Attends Sprint Planning?

This negotiable implementation is why you’ll have to estimate each user story, as they all have varying levels of complexity. With a concrete focus area, you and your developers will quickly identify your sprint goal. This sprint goal defines what your team is trying to accomplish during the sprint and will give your developers direction. If, by any chance, the transcript reveals that the previous sprint didn’t go particularly well, it’s essential to maintain a positive attitude and not dwell on the setbacks. Simply enable Otter during your sprint review or retrospective, and you’ll have the meetings fully recorded. The product owner presents the context for the work considered for the next sprint.

Good estimation requires a trust-based environment where information is given freely, and assumptions are discussed in the pursuit of learning and improvement. The purpose of sprint planning is to define what can be delivered in the sprint and how that work will be achieved. Sprint goals originated in the early days of scrum as a way to measure success for each completed sprint.

D. Decide on sprint backlog and break down user stories into tasks

Use our sprint planning meeting template to provide structure and set expectations for your team. Our template will help you define sprint goals and plan for execution. After that, the scrum master picks items from the product backlog that matches the established sprint goal. Next, he selects from the lowest item that he is confident will offer value to the end-user. Those tasks and goals are defined and agreed upon during the sprint planning session. So, as you can guess, it is extremely critical for everyone to have a fruitful and effective sprint planning meeting.

Don’t forget to describe the questions in the schedule planner online. The Product Owner’s primary goal is to represent the product and is, by default, the most knowledgeable individual about the product. While your employees are asking questions, it’s probably wise to step down and have the Product Owner take the stage.

Set a timer

For example, suppose a basketball team is in the middle of their season. They’ve scored an average of 98 points per game through the 41 games thus far. So let’s walk through four tenets of sprint planning we find most helpful.

The input would be the product backlog and the current state of the product. During the output discussion, it is critical to have a whole Scrum team agreement on what is the desired output for the current sprint. The best practice is to schedule the sprint planning in the weekly planner online at the beginning of the week so that the flow is not interrupted by the weekend. Given this long period, you want to ensure your developers understand what they’re trying to accomplish and what the objectives are.

During sprint planning, it’s necessary to come up with due dates for each user story. Due dates help drive and track the progress of each task and are significant for external stakeholder communication. After setting a clear goal, the product owner should select stories that meet the sprint goal. Ensure the stories are in line with the team’s capability and capacity. A sprint planning meeting agenda is a document that outlines the topics that will be covered during the sprint planning meeting.