Toward the end of the meeting, the team commits to work for the upcoming sprint. It’s not the product owner or the scrum master who ultimately chooses. The development team reads through each piece of work (i.e., user story) and evaluates its complexity. This is notoriously difficult, which is why increasingly teams are turning to tools like LinearB to plan more accurately. For agile development, we estimate complexity, not time required to complete. As a consequence, we assign complexity points to each story we evaluate.

Instead, you’ll need to estimate how productive they are on average. If you believe they are 90% productive, then multiply your ideal capacity by 0.90. If you think they’re closer to 80% productive, multiply it by 0.80. Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.

The product owner presents the context for the work considered for the next sprint. The product owner explains where the user stories come from, such as customer requests, customer support, or the marketing department. The scrum master will be successful when the development team has understood the limitations for the coming sprint. Photo by Kelly Sikkema on Unsplash But before a development sprint can begin, the development team must have a shared understanding of the work. They must be willing to commit to completing it in the time allotted for the sprint. Identify tasks that were started in the previous sprint but did not get completed.

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. Create, schedule, assign, and send your action items to your integrated apps, like Asana, Trello, and Jira. To have good estimates, an environment promoting trust and freely sharing information should be encouraged. Estimates are determined for the sake of learning and improvement.

Who attends a sprint planning meeting?

In this post, we’ll be exploring the basic building blocks of a sprint planning meeting agenda. Next, the PO should create new items based on the team’s discoveries from the previous sprint. 🎯 The Product Owner must be very clear on the expected customer value for the increment. Otherwise, the development team might choose a set of product backlog items that don’t relate to one another. The result could be unexpected outcomes and a low sense of accomplishment.

If anything else came up during sprint planning that wasn’t already on the radar, find a space to record those and identify action items. Chances are, the ScrumMaster, Product Owner, or other team member has received updates from outside stakeholders since the last time the team planned a sprint. It’s important to review any new information from the market or customers that help to set context for what the upcoming sprint will look like.

Then, each developer chooses the most representative number when a user story is read out. The higher numbers indicate greater complexityand the lower less complexity. Using those benchmarks, you’ll gauge if you have room for another backlog item. Finally, discuss if you have enough remaining space in the sprint. Consider how much work you’ve already allocated for it and how much you accomplished in the last sprint.

What is sprint planning? Guide and meeting agenda cheat sheet

Then, scroll down to the MindManager professional templates and open the “Meetings and Events” folder. Worst case scenario, you miss your sprint commitments and lose trust among your team. Best case scenario, you hit all your deadlines and your team still doesn’t trust you. The Product Owner’s primary goalis 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 Ownertake the stage. Instead of forcing rises in velocity, use the metric as a benchmark for how much work your team can realistically take on. With this tactic, you ensure the frankness of your developers. This method is handy if you’re worried that your developers won’t be truthful or will just go along with the majority. Distribute a survey to your developers , and have everyone include their input that way.

About this sprint planning agenda template

Ask your team about a specific, recurring time to meet, and ensure it works for everyone. The sprint planning meeting is an ideal time for team members to discuss important aspects of the project. This creates the opportunity to ask questions, provide feedback, and assess how much work they can complete.

Prepare for your next sprint with this sprint planning agenda template. Review goals, define scope, and make decisions collaboratively. To reiterate, the development team decides what to work on in the next sprint. The product owner and the scrum master are not responsible for making the final decision. It is the product owner’s responsibility to determine what constitutes meaningful work and why it is essential. The development team is responsible for assessing and selecting tasks for the subsequent sprint.

Sprint planning best practices

LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals. Tradeoff decisions may need to be made during these discussions. Engineers define implementation complexity and how much work it can commit to.

These were prepared by the Product Owner and organized by value. It should be roughly the size of two sprint’s worth of work, just in case the team has questions about how this work will relate to future work. Secondly, the scrum master brings forth any time limitations for the upcoming sprint, like vacations and holidays. Ensure the team breaks down the prioritized story into small manageable tasks. Smaller tasks will help the team evaluate the activities they need to do to complete their stories.

Holding a sprint planning meeting gives the team a chance to discuss how long a project might take based on everyone’s capacity to take on tasks. This prevents teams from setting unachievable goals because everyone can contribute insights as to how much work can realistically be accomplished within the sprint before it begins. This means that items are organized, dependencies identified or removed, test cases are written, acceptance criteria is listed, and all descriptions are set. Without this prep work, the sprint planning meeting is less efficient and more time-consuming for everyone.

• Regardless of the voting mechanism used, the goal is to achieve a team consensus where team members are comfortable with the complexity score assigned to each story.
• Book a meeting room with plenty of space for your team, and consider separate spaces for breakout sessions.
• All of these should be addressed so the team has an accurate idea of how much dedication they’ll have to this sprint.
• They must be willing to commit to completing it in the time allotted for the sprint.
• This is often done by breaking down projects into story points or estimated hours of work.

The sprint planning ceremony is usually led by the product manager, product owner, or scrum master. This includes engineers, QAs, and designers, each of whom is critical to the sprint planning process. Asprint planning meeting is a session in which the product manager and development team plan the work the team will commit to for the upcoming 2–3 weeks.

Don’t Lose Sight of the Product Vision

Putting these elements together is essential to reach a defined print objective. It’s easier to understand the sprint goal, to-do work, and sprint outcomes with a successful Sprint Planning meeting. If the team doesn’t know where it’s heading and how to get there, it gets really tough to satisfy customer needs. It’s equally hard to deliver your customers valuable increments if you don’t organize work by priorities. Setting unrealistic expectations for the increment that the development team can produce over a sprint is not a good idea. It might make developers frustrated that they couldn’t deliver, which can seriously affect their motivation and performance.

When should you have backlog refinement?

Atlassian’sConfluenceis a popular option used by many companies worldwide. Congratulate your developers on what they did accomplish, and get them excited for what’s ahead. They’re sure to remain motivatedand will likely tackle the next sprint in high spirits. Similarly, the ScrumMaster should be noting any other related impacts that may arise from the sprint plan getting put together. The only way someone knows if something is complete is if there is a clear description of what “done” means. Also, team members may have been moved around or added since the last sprint.

Among her interests are artificial intelligence, machine learning, and natural language processing. As a humanitarian and educator, she actively supports women in tech and promotes diversity. Assign a relative size (e.g., small, medium, large) to each item based on its complexity and then group similar items together. Affiliate Partners Promote the #1 SaaS productivity tool, and make a lifetime 30% recurring commission. Content Planner PRO Turn your list of keywords into a content plan with keyword clustering for maximum velocity. Watch now to learn how to create unique, engaging content that will make your business stand out.

For each selected Product Backlog item, the Developers plan the work necessary to create an Increment that meets the Definition of Done. This is often done by decomposing Product Backlog items into smaller work items of one day or less. How this is done is at the sprint planning meeting agenda sole discretion of the Developers. No one else tells them how to turn Product Backlog items into Increments of value. The Product Owner ensures that attendees are prepared to discuss the most important Product Backlog items and how they map to the Product Goal.

How to prepare for a sprint planning meeting

It’s easy to fall into bad habits, especially as deadlines and product launch dates approach. Avoid these common agile planning mistakes to ensure your team is always making the most of the agile methodology and the Scrum process. Sprint goals should always align with your broader product goals.

Second, that the developers make good choices when moving product backlog items to the sprint backlog. Selecting an item that is feasible for the sprint duration, team capacity, and workload is a good choice. If done right, the product owner will have a complete understanding of the details of each feature, so that she/he can answer any questions. The best sprint planning meetings blend strategic alignment with tactical planning. When sprint planning is done well, team members leave the meeting feeling motivated and excited about the work ahead.

We mentioned this point when we talked about what you need to do to prepare for sprint planning. Depending on the tool you’re using to plan and manage your work, it can be difficult to see the contextual detail needed to plan and work with clarity. The more items you have, the more difficult and overwhelming it will be to organize and prioritize. Use tools that allow you to add context, depth, and customer insights with clean functionality to adapt your plan to the needs of your team and stakeholders.

So, have your https://globalcloudteam.com/ prepared, and let’s explore how adam.ai can help you execute and organize all your sprint planning meetings effectively. The preparation of the sprint planning meeting falls mostly on the shoulder of the product owner. The scrum team, including the product owner, scrum master, and developers, attends the sprint planning meeting. Here are the definitions and responsibilities of each role as quoted from The Scrum Guide. The article also includes a free sprint planning meeting agenda template and a detailed explanation of each agenda item.