How To Run A Sprint Planning Meeting Effectively

In these cases, do not consider these stories as valid sprint backlog candidates. Rather, in order to consider for sprint planning, split the stories into smaller pieces. Additionally, each story must be able to stand on its own as a vertical slice. Therefore, stories should not be incomplete or process-based as a horizontal slice. The product backlog collects all the development team’s goals for the entire project. But if you try to work on all your product backlog items in one sprint, you’ll get nowhere.

This step is where story points come into play — another reason why it’s helpful to estimate story points through a process called planning poker. Story points are numbers that assign value to the amount of effort that a user story will require. Let us discuss some of the major benefits of sprint planning meetings. Try it as is and determine if its philosophy, theory, and structure help to achieve goals and create value. The Scrum framework is purposefully incomplete, only defining the parts required to implement Scrum theory.

The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, How Sprint Planning Helps IT Teams they participate as Developers. They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint. The fundamental unit of Scrum is a small team of people, a Scrum Team.

The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed. The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work. Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox. These values give direction to the Scrum Team with regard to their work, actions, and behavior. The decisions that are made, the steps taken, and the way Scrum is used should reinforce these values, not diminish or undermine them.

Estimate Stories & Points

Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

• The scrum team members are the players or development team that will put into action the steps or plays that will help win each quarter of the game.
• The start of any Sprint in a Scrum Framework is Sprint Planning.
• Teams increase the chances of making a valuable product improvement during the Sprint when tasks are connected to a meaningful Sprint Goal during Sprint Planning.
• This means that all of these items are properly identified, test cases have been written and all the descriptions have been set.
• Don’t delay any future work that’s blocked by the story you’re deprioritizing.
• In the first session, the product owner reviews the list of features and defines what needs to be built during the next sprint.

Each item below is one of our best practices for sprint planning. We discovered them all through hard work and a lot of failing forward. In our SaaS example, the product owner wants a complete user dashboard by the end of the sprint.

Sprint Planning: Part Two

The one prerequisite for this ideal approach is that your agile team or organization actually has a Scrum Master, which isn’t always the case. A Product Owner also has enough work to do before and during Sprint Planning, even when they’re not leading the meeting. It’s usually a welcome relief for them when someone else facilitates the event.

Scrum Master and Product Owner roles do not have regulated official participation in this technique. The Scrum Master role participates in its discretion without interfering with the team and can monitor transparency, respect for team members, and honesty. After the discussion, a re-play is performed, and each participant of the Development Team throws a card again. Other participants’ opinions may already have been influenced.

The objective of sprint planning is to work out the key details regarding the team’s planned work during the next sprint. With that in mind, the sprint team should plan to address at least the following issues during this meeting. Before we get into the steps of this meeting, some preliminary work needs to get done.

Plan, Track, & Support

Sprints are not something to do without careful, strategic planning. Because the sprint is so important, poor planning could cause delayed or unmet goals. Don’t try to plan every single thing during Sprint Planning. Leave the idea of coming up with the most complete, perfect Sprint Backlog ever at the front door.

After you’ve clearly presented the lessons from the last sprint in the template, a bit of time is all that’s needed to help them settle in. During the retrospective, use the monday.com sprint retrospectivetemplate to organize everybody’s thoughts. On their own, your team members can digest the lessons from the previous sprint and experiment with ways to act on those lessons. The time between retrospective and planning is actually vital processing time.

Make sure to include action items from the last Sprint Review and Retrospective in your plans, and address any unfinished work from the previous Sprint. Scrum expert and author Mike Cohn recommends having two Sprints worth of Product Backlog items ready for Sprint Planning. That rule of thumb gives the development team sufficient work to choose from, but not too much for the Product Owner to prepare.

Why Is Sprint Planning Important?

You can also discuss feedback from the customer to provide your team with context and guidelines for the work ahead. If you have a two-week sprint, run a backlog refinement meeting in the middle of the sprint. It’s great for the team to step back from the sprint and look at what’s next. Not only does it help prepare for sprint planning, but also can give a different perspective for the current work.

A sprint planning meeting is conducted before the start of a sprint. The purpose of this meeting is to determine the sprint plan and set a 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. Building sprint planning into the company’s culture forces the cross-functional team to regularly review its product backlog — and to keep the backlog from becoming a black hole. It encourages the team to frequently review and identify the most strategically advantageous development work to undertake next.

It’s best to have it at the start of a week, so it leads right into 4 unbroken days of productivity. Jira IntegrationTurn action items generated in Fellow into Jira issues so their completion status stays in sync between both tools. Slack IntegrationCollaborate on meeting agendas, share notes, and exchange feedback – without leaving Slack. Google MeetUse Fellow’s Google Meet extension to collaborate on meeting notes and record action items, right within your video calls. ProductFeatures OverviewSee how high-performing teams are using Fellow to level-up their meeting and productivity habits. The goal of the How-Meeting is to fill the Sprint Backlog by identifying the concrete tasks needed for complete implementation of the Scrum Product Backlog entries.

Sprint Planning

Project managers often think they’re saving time by doing it this way. Meetings to plan other meetings sound like the exact opposite of Agile methodology. ResourcesBlogLeadership, productivity, and meeting insights to fast-track your way to being a great leader.

You’ll need to spend some time planning in order to get a better understanding, and this may include having to estimate and redefine work items. In scrum, a sprint is a set period of time where work is done – typically 2 or 4 weeks in length. Each sprint begins with a sprint planning meeting to define focus, deliverables, and how it will all be accomplished. The objective informs most other decisions during the meeting, like the set of product backlog items to select.

There’s no set standard for how much your team should complete in any given sprint. Your velocity will depend heavily on how long your team has worked together, how many backlog items have been prepped to complete, and how effectively you’ve planned your sprint. Before a sprint begins—and ideally prior to a sprint planning meeting—the product owner should groom all existing product backlog, also called backlog refinement.

How Do You Run A Sprint Planning Meeting?

However, the more the Developers know about their past performance, their upcoming capacity, and their Definition of Done, the more confident they will be in their Sprint forecasts. Most importantly, the product owner and Scrum master should give their endorsement of the plan and encourage confidence and enthusiasm from the team moving forward. Confirm your team’s availability for each stage of the project and make sure that your team is aware of the current velocity. Update your team on any newly added team members or shifts in responsibility that may have occurred since the last sprint. Scrum is a process framework aimed at solving complex problems. Empirical processes are very hard to plan, so don’t kid yourself–you can’t build the perfect plan.

Prior to the Spring Planning meeting, the Product Owner reexamines the Product Backlog and makes adjustments where necessary. This process is officially called product backlog https://globalcloudteam.com/ refinement . With the help of the team, the Product Owner needs to ensure that every story to be discussed in the meeting is of equal size, and not too long or too little.

Reward Your Team

Once the goals are fixed for the Sprint, make sure that you do not change it. Often a situation arises where high-priority items and stories come in between; at such times, it is important to take acceptance from everyone and take a joint call on the way forward. However, in the best interest of the Sprint, the goal must never get changed mid-way. When you have an agenda and a roadmap before the start of the meeting, you have a direction on which the team can work, optimize their time, and stay focused.

Use Lucidchart to provide you and your team with visuals that will organize your vision for your upcoming sprint and align your team on sprint goals. Learn how our visual workspace can revolutionize your Scrum team’s approach to planning and completing your 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. Sprint planning is about gathering the necessary people together to determine the product development goal and work you will do in your upcoming sprint. But before you get to a planning meeting, there’s a reasonable amount of prep you need to do to organize.

Engineers define implementation complexity and how much work it can commit to. Just because a story is dev-complete doesn’t mean it can be released; there needs to be testing capacity too. Estimate the timeframes for each of the tasks assigned and agree on what “done” will look like for each item. All of these should be addressed so the team has an accurate idea of how much dedication they’ll have to this sprint.

He/she also needs to ensure that the team has the necessary supplies and information with them so that the meeting can happen smoothly. Since Sprint Planning is so critical for achieving the purpose of the Sprint, it needs to be effectively planned. Depending on how long your sprints are you may want to increase the time spent during topics 3 and 4. Your aim with this last check is not to start from scratch, but to rephrase or resize the Sprint Goal—ideally just slightly—based on any final feedback that comes up here.

A backlog refinement process must be set in place, resulting in having work items reach a Definition of Done; which is when they’re ready to be considered for inclusion in the Sprint. It is important to take as many tasks for the Sprint as is achievable and actionable in the given duration. You could estimate the number of tasks to be taken based on your previous experience. In Scrum, projects are broken up into 2 or 4 week sprints.