Sprint Planning - Starting with Scrum

This is the fourth article in the 'Starting with Scrum' series. In the first article, we discussed how to get started with Scrum by determining what the Product Goal is. In the second article, we talked about how to translate the Product Goal into a backlog. In the third, we looked at Product Backlog Refinement.

Want to read the full Series? See below:
>> Starting a new product in Scrum
‍>> The birth of the Backlog
‍>> ‍Backlog refinement in Scrum

In this article, we pick up where we left off and get started with the first Sprint!

What is Sprint Planning?

If you look closely at the 5 Scrum events you will notice that Sprint Planning is actually the very first event that takes place. This is the moment of truth, when all the preparations come together as the team gets ready to start their first Sprint.The Sprint Planning meeting is the Scrum planning session that is conducted to plan the upcoming sprint. 

Planning meetings enable employees to brainstorm ideas before initiating the new project. These meetings assist companies in coming up with creative ideas, creating plans of action, and holding discussions on the project's scope. The primary objective of a planning meeting is to plan out the tasks, create execution strategies, and assign roles to team members. These meetings also strategize on the chronological order in which the tasks should be performed to meet project deadlines.

Having used the sprint review and sprint retrospective process to understand what happened in the last sprint, the main purpose of sprint planning is to define goals that are achievable in the next sprint along with the processes needed to attain these objectives. The Scrum Guide offers well-defined instructions to overview the matters necessary in a sprint planning session. It also compels attendees to review leftover tasks from the last sprint and create an appropriate action plan to bring them into the fold. 

An agile planning meeting also has a

proper structure. However, according to research, managerial and executive-level employees believe that half of the meetings are a waste of time. Therefore, for a planning meeting to be successful, it must be precise, to the point, and meet all its objectives in a limited duration of time

According to the Scrum Guide, Sprint Planning covers three topics:

• Why is this Sprint valuable?
• What can be Done this Sprint?
• How will the chosen work get done?

Why is this Sprint valuable?

Having developed the backlog together in the previous articles, the team is yearning to get started. Perfectly aware of the Product Goal and having worked out the first priorities into a Product Backlog, the team – and especially the Product Owner – come to the Sprint Planning with a clear idea of the first step that needs to be taken. Now is the time to express that first step as a Sprint Goal. This is important because just like with the Product Goal, it gives the team a clear vision to focus on, this time at the level of the Sprint.

We also explain why the Sprint is valuable. We talk about value because that is the currency of our work. The Scrum Guide tells us:

“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.” – Scrum Guide

The complexity that Scrum is designed to address requires a measure that is tied closely to the outcome we seek, and that is value. It’s a bit too complicated to discuss here in further detail, but check out this article if you want to know more.

If there is disagreement about what the Sprint Goal should be, I like to organize a quick 1–2–4-all to collect the various ideas for the Sprint Goal. A clear overview of the thoughts of the whole team will often lead to a creative synergy that makes it easy to find a single powerful Sprint Goal. At the same time, giving everyone in the team the opportunity to contribute leads to ownership of the goal and greater motivation.

Whatever the case, I’ve found defining the Sprint Goal away from the backlog works best. It helps keep the focus strictly on the Product Goal, and helps to make the Sprint Goal a faithful stepping stone towards it.

I have found that the mere presence of the backlog can have a strong impact on the team. This is very much human nature, a result of cognitive load. All the individual work items – each with its own urgency and purpose, beckoning the team to click on them and get lost in the details – create confusion and make it really hard to keep sight of what is important. The trees obscuring the forest, so to speak.

What can be Done this Sprint?

Once clear on the Sprint Goal and with a firm commitment from the team, it is time to collect the work to achieve it. Having the Sprint Goal makes it ‘safe’ to look at the backlog, as it makes for a very strong criterion to sift through the available work items. We are not looking at the backlog to create our focus anymore; we are looking at the backlog to fulfil that focus.

One thing to keep an eye on during this process is the capacity of the team. Developers generally have two very positive characteristics: They are ambitious and they are optimistic.

It is therefore important to at least make them aware of the fact that they need to think about what will fit in the Sprint. This is an important skill to learn as a team, to improve their Sprints: too much work and the team will work under stress, struggling to achieve the Sprint Goal, too little work and the team will run out of work during the Sprint, which often also leads to stress.

Note that the focus here is on learning. Whether the team gets it right or not is irrelevant. Work is getting done, one way or the other, so the learning doesn’t cost anything. In fact, the more often the team gets it wrong, the faster they will learn. This means that we can focus on creating safety for the team; simply having a laugh at how far off we were can be enough.

How will the chosen work get done?

Having collected the necessary work items to achieve the Sprint Goal, it is time to get started on the final step of the Sprint Planning: determining how the work will get done. In general, I’ve noticed that teams often skip this step. This happens because the work items have been worked out so extensively during the refinement, that the ‘how’ is completely obvious.

As I discussed in the previous article, this has a lot to do with confidence. It takes courage for a team to accept that they don’t need to figure out everything about how to deliver a user story until the Sprint Planning. This reflects on the length of the Sprint Planning: Some teams will spend no time at all on this step, having prepared everything in the refinement. However, the ideal is leaving the ‘how’ to the last responsible moment, and that is this step.

Incidentally, an interesting thing to notice at this stage is whether the team writes new work items. I find this a significant indicator of whether the backlog is leading, or the Sprint Goal.

One of my favourite approaches here, working with a team that really leaves figuring out the how till this moment, is organizing a Shift & Share. We will split into 2 or 3 teams, and in separate breakout rooms prepare our approach. Once everyone is ready, we will take turns presenting the plan to each other. It is so satisfying to see how results are often complementary, with different groups focusing on different perspectives! Combining these gives the team not only a very reliable plan, but also serves to reinforce the value of all the individuals in the team.

After that, and depending on the complexity of the work, especially the existence of dependencies with other teams or events, I sometimes like to set up a timeline where we can visually plan the work over time. This also helps to discuss other things in addition to the regular work. For example, meetings with other teams. Knowledge transfer moments. All the things that teams will often hesitate to include in the backlog.

True to the Agile principle of finding our way while we work, I will leave it up to the team to leave the planning of lower-priority work items for further on in the Sprint. I find that it is often more efficient to plan some work after having made an initial delivery. The knowledge that is gained makes it possible to plan the rest of the work appropriately.

Conclusion

For me, the Sprint Planning is the most important event to get right in Scrum. It is the one event that shows best how mature a team is. For a long time, it was the milestone I worked towards, convinced that so many things had to be in place before it would be a success. The refinement must work efficiently, the backlog must be in order, the team must understand what the Daily Scrum is for, etc.

It was Maarten Dalmijn who quite casually told me that with a new team, he always starts with the Sprint Goal. That was a watershed moment for me. It made me realize that Scrum can be as simple as that: start by focusing on the Sprint Goal and all the rest will automatically fall into place, in service of that higher purpose.

I find that this maybe is the key element that distinguishes Scrum:

• Scrum is not about delivery. It’s not an output-driven approach driven by incoming requests, where the content of the Sprint is determined by the available work items in the backlog
  
  

Scrum is about a creative process driven by vision, an outcome-driven approach where the Sprint Goal determines which work items will be picked up during the Sprint.

More about Sprint Planning
>> When do teams start Sprint planning?

>> Sprint planning agenda

>> Backlog grooming vs Sprint planning

>> The timebox for Sprint planning event

>> Sprint planning meme

Sprint Planning FAQs

What is the Sprint Burndown Chart?

This is an integral part of the agile sprint planning meeting. It's a graphic of how quickly the backlog of a sprint is completed, which should (if all goes according to plan) slope downwards, and come to an end by the time point of the sprint’s completion. 

As stories are completed, the graph curves downward more sharply. It confirms how much work remains, NOT how long it takes to do it! 

In the best case scenario, the sprint burndown chart has a very sharp slope downward; in the worst case scenario, the burndown chart remains pretty flat. 

What are User Stories, Estimations, Splitting and Mapping?

There’s a lot of estimation (based on experience and past sprint reviews) during the agile planning meeting. 

The team obviously needs to estimate what they can legitimately do during the sprints, according to their capacity and planned velocity of completed items. 

But - and it's a big ‘but’ - estimation is NOT the same as ‘commitment’. Here’s why:

• The product backlog will be split into user stories. This will likely be sorted according to the product owner, not the actual Devs who will be working on them. 
• These stories will need to have an overestimation assigned to them, regarding the time they will take to complete. 
• These user stories will likely need to be split down into smaller chunks of manageable user stories. 
• Once these have been split, they need to be mapped out according to time, assigned owner, and overall priority. 

Only once all stakeholders have signed off on these, do they become a commitment.

Sprint Planning Meeting Example

Sprint planning does not have to be a complicated thing! Here’s a quick breakdown of who does what, when, where and how: 

What: 

The product owner will share their objective for the sprint - for example, to develop a new feature. They'll then sort the backlog items related to that objective. The scrum team will have to decide how to make the objective happen. 

How: 

The Dev team works together to plan out what they need to make the objective happen on their end. It’s worth mentioning here that the sprint planning meeting is often a sort of negotiation between the outcomes set by the Product Owner, and what the Dev team can realistically deliver. 

Who: 

The Product Owner, Dev team and any other relevant stakeholders will be present at the sprint planning meeting. It's incredibly important that all stakeholders are relevant, to say their piece and offer realistic goals… or someone could end up with more work (and unattainable goals!) than they'd bargained for. 

The Outcomes

Perhaps the most important aspect of the whole agile sprint planning meeting are the outcomes that are set and agreed on. Anything agreed upon will be broken down into stories and added to the sprint backlog, ready for everyone to start working once the sprint commences! 

What is a Sprint Planning Meeting Agenda?

Unlike other areas of the Scrum process, sprint planning meetings require a solid structure, patience and collaboration. 

You can expect a mix of: 

• A refined product backlog, ready to go with the Product Owner’s needs.
• Outcomes and action items from the last sprint review, for reference.
• Calculations of commitments - both past and present.
• Determining the velocity and capacity of the team during the upcoming sprint, according to stories and overall goals.
• Story estimations - the team will do their best to estimate how long each item will take to complete, budgeting time and timeline. 
• Capacity estimations - once you have the above two steps down, the capacity of the sprints can be worked out, as well as the speed of story completion. 

In general, the sprint planning meeting will follow this structure (but you may do it differently, depending on your team’s needs):

1. Overview and big picture sharing.
2. New information for the upcoming sprint.
3. Capacity and velocity discussion.
4. Known issues discussion (according to sprint review outcomes).
5. New backlog items to add to the sprint.
6. Set estimates for work .
7. Discussion of the overall plan and confirmation of stakeholders. 

What’s Included In The Sprint Planning Meeting Agenda?

The sprint planning meeting needs an agenda in order to keep team members focused on necessary tasks. Also known as the Product Owner meeting agenda, these are working sessions conducted at the beginning of each sprint where the entire team agrees to tackle product backlog pieces. 

It's crucial to set the stage for the team and sprint meeting by articulating goals to the team members and attendees. The Scrum meeting agenda framework should: 

1. Closing Last Sprint

In order to move forward successfully with your next sprint, it is always advisable to review the activities of your last one. It's essential to evaluate the remaining tasks from the previous sprint before moving ahead. Do not forget to decide on unfinished tasks and celebrate the tasks achieved. 

2. Clarifying Team Availability

This outlines the roles performed by each team member during a sprint. It is the responsibility of a Scrum Master to set the infrastructure while ensuring all of the teammates are available during the meeting. Indeed, vacations, holidays, and project completion need to be addressed beforehand to give an accurate idea of the team's dedication.

3. Setting Sprint Goals

Everyone should know what their team plans to achieve throughout the sprint. It's an overarching summary of projects and goals explaining the implementation of backlog pieces. But, most importantly, it focuses on the scope of the sprint, allowing its team to discuss complex elements before starting the project. 

4. Bringing the Backlog to Order 

It's the responsibility of the Product Owner to collaborate and organize all backlog items that need attention in a sprint meeting. But first, make sure the backlog items involved in the sprint are ready to be worked on. 

Here the product owner describes the backlog item focusing on the problem statement while ignoring the implementation. Showing where the problems occur in the current solutions is always better than just explaining it with words. 

5. Presenting Velocity 

Velocity is unique to every team. Hence, never employ another team's velocity to strategize your agenda for sprint planning. Instead, aggregate the story points over completed sprints and opt for cross-training to increase your team's velocity. Ensure that team members are fully aware of the current velocity needed for the sprint backlog. This way, team members don't have a chance to select stories and attack in the sprint. It's always best to keep it in the back of your mind rather than relying on a gut feeling. 

6. Discussing Acceptance Criteria

This is where true collaboration and negotiation come in handy. This sprint review meeting agenda makes sure the team reviews each item and agrees on acceptance estimates. In addition, an agile sprint planning meeting agenda must discuss acceptance criteria where it should highlight the success factors for a backlog item from a business perspective. 

7. Estimating Complexity

It is crucial to predict the complexity levels of a backlog, and one way to do so is to compare it with others. Here, one doesn't consider time estimation; instead, we focus on the availability of team members. 

Why are Sprint Planning Meetings Important?

Sprint planning meetings play an integral role in making sure the project runs smoothly. A successful planning meeting can: 

• Distribute tasks 
• Facilitate teamwork 
• Encourage teams to stay on schedule 
• Give teams clear direction to accomplish project goals 

In simple words, sprint planning is a short, time-boxed working session where the entire team agrees to complete product backlog items. It's based on the team's velocity, sprint backlog, and length of a sprint. 

It's a collaborative effort that involves the Scrum Master, product owner, and the entire agile team committed to meeting their sprint pledges. It’s a popular technique that breaks up larger agile methodologies and projects into manageable tasks. 

When Should You Conduct A Sprint Planning Meeting?

As stated earlier, sprint planning meetings are held before starting work on a new project. However, to make the meeting more productive, you need to consider a few factors. 

Availability 

An agile planning meeting must include all the relevant personnel. This means all team members that play a role in the project should be present in the forum. For this reason, you need to arrange the meeting at an optimal time when all team members can attend. 

In the unfortunate case that you can't find a suitable time for all employees, arrange the meeting in a hybrid format to make sure that all workers are present. This way, you can discuss the ideas in detail and ensure that the entire team is on the same page. 

Budget 

Another factor that you need to consider is the project budget. Schedule a meeting only after the funding for the project has been approved by the key stakeholders. This way, your teams can plan the tasks appropriately and ensure that the cost does not go over the set amount. 

Project Deadline

The project deadline is another factor that you need to consider before hosting a planning meeting. An agile planning meeting is set as early as possible, as it provides the team with ample time to execute the tasks sensibly. 

What Are The Best Practices Of Running A Sprint Planning Meeting?

18 Best Practices for running a Sprint Planning Meeting

Sprint planning meetings best practices really run the gamut of anything and everything, and depend on the way your team does things. These sessions are only as good as what you put into them. And trust us, there’s a lot that could be put into them.  it’s all about knowing how to use this time effectively for the best sprint ever (or as close to that as possible). Check out

Before Session Best Practices

1. Create a Planning Committee

The most important factor in an agile planning meeting is the people attending it. Before scheduling a meeting, the attendee list must be confirmed. The attendee list should can vary from project to project, as you only invite the relevant individuals to the meeting. This practice ensures that the discussion remains engaging and other workplace operations are not disturbed

2. Refine the backlog 

The Product Owner should have a refined backlog ready and waiting for the team as a top priority. Without this, the whole sprint planning session could waste countless precious minutes (or even hours) on trying to prioritize user stories (which, while we're on the subject, should be ready and updated with all the necessary information). 

3. Have an agenda and roadmap ready 

Having a sprint planning agenda and roadmap ready and waiting to go before the actual planning session will save you valuable time and effort, and help you avoid any potential distractions. 

3 In-Session Best Practices

1. Schedule the session correctly

One of the most (if not the most) important sprint planning best practices is to give your sprint planning session enough time. A good way to estimate this is to allow an 8-hour time block per 1-month sprint. So, if your sprints are 2 weeks long, your sprint planning session should be allotted at least 4 hours. 

2. Brainstorming with product backlog alignment 

The Product Owner will kick off the meeting, detailing the User Stories’ order of priority and how they align with the roadmap. 

The Dev team will then start assigning the backlog’s User Stories, and seek clarification if needed. 

3. Sprint goal-setting

The sprint goal is one of the most important aspects of the entire sprint planning session. Knowing what the end goal of the sprint is will go a long way in helping the team work backwards to understand how it needs to be broken down, and how it will be achieved. 

(Pro tip: One of the most important sprint planning best practices is to have your sprint goal be SMART-focused).

Click here for the full 18 Sprint Planning best practices.

Sprint Planning Meeting Templates

Using a sprint planning template will help the entire team to align in sprint goal setting, capacity estimations and make each sprint as effective as it can be. 

Using a sprint planning template will allow you to:

• Close the previous sprint decisively, and with learning outcomes
• Get your team aligned with the upcoming sprint’s goals
• Plan the team’s capacity
• Share the team’s projected velocity 

Check out some solid examples of sprint planning templates from Asana and Monday.com. 

Asana

Monday.com

Activity Ideas For Your Sprint Planning Meeting

The sprint planning meeting activities relate around dissecting the product catalog, and assigning user stories: 

• Discussing and setting the overall sprint goal.
• Reviewing the highest priority stories and the product catalog. 
• Determining what the Dev team can and can't do (estimating) according to their capacity and velocity. 

What are the Challenges in Sprint Planning?

As you're well aware, there are all kinds of issues that can go wrong during a sprint...but, having a sprint planning meeting can help to prevent any and all of these issues from even happening! 

Here’s what to expect and how to do a sprint planning meeting to anticipate these challenges: 

• Make sure there’s a clear, defined sprint goal
• Allow room for changes during the sprint
• Anticipate any and all issues that could arise - if not for the current sprint, then take note for the next sprint.
• Overestimate the time it will take for stories to be completed. 

Backlog Grooming vs Sprint Planning

What’s an Agile Backlog, and What’s Backlog Grooming?

Your agile backlog is literally the backlog of tasks you have waiting to enter your sprint, usually in order of highest priority to the lowest. 

“Backlog grooming”, aka “backlog refinement”, is taking that agile backlog and making it fit and ready to enter your sprint. Just as in life, ‘grooming’ is the process of cleaning and beautifying. In this case, backlog grooming refers to the sprint at hand. 

In practice, agile backlog grooming keeps your backlog updated and relevant, while getting the entire backlog ready and refined for the upcoming sprint. In reality, you need both to help your sprint run effectively without a hitch. 

Backlog Grooming Vs Sprint Planning

Although both types of meeting sound the same, there are a few important differences: 

• Your agile backlog grooming is the semi-finished list that is presented to all members in the sprint planning session. 
• Your backlog grooming meeting has to happen before the sprint planning, or your sprint planning session won't go as effectively (or as quickly). 

When it comes to your backlog grooming meeting, it is up to you to decide who should be present; however, once the backlog has been groomed and is ready for the sprint planning meeting, we recommend that all stakeholders are present to plan for the sprint. 

See here for a full comparison of backlog grooming vs sprint planning.

Final Thoughts about Sprint Planning

The sprint planning meeting is a precursor to the sprint. If it’s not up to scratch, the outcome of the sprint will suffer. The planning session should leave each team member with two outcomes: detailed information and focus.

Firstly, make sure the team is aligned on all aspects of the sprint - ownership of tasks, the sprint backlog and the sprint goal should be known by each team member otherwise the team faces the problem of being disconnected.

Secondly, each team member should be aware of their own exact tasks and what it takes to complete them - this will ensure that team members don’t stray from the path of the sprint. Remember that planning is also just that, planning. Almost always unplanned events come into the sprint but a good sprint plan should allow these events to not derail the whole sprint - so allow room for unexpected items that might pop up.

How GoRetro Will Sort Your Sprint Planning Meeting, Period.

If a sprint planning meeting, the sprint itself, and everything that comes after sounds like too much work for you, then let's GoRetro.

With GoRetro Planning, you can engage in the most comprehensive, data driven sprint planning exercises to prepare the team for the upcoming sprint. In one place you can set up your capacity roadmap, sync with the team on estimations and see your velocity, carryover, buffers, and planned-versus-actual trends with our deep Jia integration. 

Everything you need for exceptional sprint planning can now be found in one place, with GoRetro Planning.