How confident does the team feel that they’ll be able to meet the sprint goal. If the team finds unique stories as they break down work, promote those tasks to fully independent stories. Once the product owner presents their ideas for the sprint forecast, the team can validate (and/or adjust) it and agree to a plan of action for the sprint.

If not, identify the amount of effort left on any stories or tasks that are rolling over. Taking these into account ensures you won’t overcommit to new work by approaching it as if you have full capacity (because you don’t). Sprint planning is an important scrum ceremony in which the scrum team decides what work it will commit to in the upcoming sprint.

best practices for sprint planning meetings

In addition, choose goals and objectives for the upcoming sprint. With this visualization, you can gauge how much velocity will realistically fit into the upcoming sprint and, consequently, how many story points you’ll be able to include. With a concrete focus area, you and your developers will quickly identify your sprint goal.

If you’re building a new product that may take several sprints to be MVP-ready, it’s tough to define useful sprint goals. It can be tempting to set a goal to deliver all committed stories in the sprint, but this puts your focus on output rather than outcomes. 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. The What – The product owner describes the objective 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 that happen.

What is sprint planning?

This should take into account current team members, public holidays, vacations, and other factors that can affect available time. Before every sprint, the product owner sprint planning meeting agenda will estimate the velocity – the amount of work that will need to be done during the sprint. This will vary from team to team based on their schedules and capacity.

• AMAs Run simple Ask Me Anything sessions across your team or organization.
• Given this long period, you want to ensure your developers understand what they’re trying to accomplish and what the objectives are.
• The development team is successful when they have clearly understood, evaluated, and embraced the work for the upcoming sprint.
• But good planning pays numerous dividends once the sprint starts.
• During sprint planning it is easy to get ‘bogged down’ in the work focusing on which task should come first, who should do it, and how long will it take.
• This is notoriously difficult, which is why increasingly teams are turning to tools like LinearB to plan more accurately.

Evaluating upcoming work means that each team member gives their estimation for a user story based on the information presented and each member’s experience. 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. It’s simpler than an absolute estimation of time because it’s independent of circumstances that are not inherent in the backlog item. For instance, who is doing the work and availability of team members during the sprint.

A Guide to User Story Mapping: Templates and Examples (How to Map User Stories)

Some teams make this a formal event, while others keep it as informal as saying, “Let’s get it done! ” It’s worth repeating that the development team picks what they’ll work on during the next 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.

Ask the team whether the scope of work leaves slack time to address unexpected issues. The Development Team picks the Product Backlog items needed to meet the Sprint Goal. If the business objective and team capacity do not match, try to strip down the Sprint scope. The Scrum Team in question was rather large—eight developers—, mostly co-located with two or three team members joining remotely.

Step 5: Wrap up the meeting

The Scrum Team may also invite other people to attend Sprint Planning to provide advice. Unplanned work can arise in the middle of a sprint and set your commitments off track, but it doesn’t have to be that way. As a product manager, it’s your job to assess and decide whether something is important enough to be pulled into the in-progress sprint.

Distribute a survey to your developers , and have everyone include their input that way. Ask yourselves what needs to happen for the stakeholders to consider the item finished, and you’ll have your answer. The easiest way to determine availability is to look at your employees’ calendars. As shown above, Confluence’s main appeal is its collaborative editingfeature.

Support for Server products ends February 15, 2024

The Scrum Master provides the team with a target velocity for the current sprint, which must be agreed on with the rest of the team. Once you’ve prepared for sprint planning, it’s time to run the meeting. We’ve already discussed how to determine capacity based on rollover work, resource availability, and other factors, which are all important to running a successful sprint planning. Start your sprint planning meeting by following up on any open question from the previous sprint. Review the story points and use our template to record what was completed and what needs to carry over to the new sprint. Once you review what you achieved, you’ll be ready to present the current sprint’s goals.

You are required to list and describe the deliverables here. For each deliverable, name it and describe it by listing its requirements. Select the team member who manages the complete creation of the deliverable.

Who is involved in Sprint Planning

In order to achieve this ultimate goal, there are two supporting intermediary goals that also have to happen during this meeting. Once you have a sense of what needs to be carried over from last sprint, you can move in some new tickets for this sprint and assign them to your team members. If your team is working on ongoing projects, https://www.globalcloudteam.com/ this might be a fairly straightforward process, because the next steps are clear. This isn’t a post on how to properly make a product roadmap. But simply a reminder to ground yourself in your long-term vision before getting swept away by sprint planning. They should always get you closer to the ultimate vision of your software.