Sprint Planning Meeting Agenda in Scrum

As we continue to dive deep into the worlds of Agile and Scrum, the next topic we’d like to cover is sprint planning meetings.

An essential part of the Scrum project management process, sprint planning meeting plays a big role in determining the project’s success. Today, we will look into what sprint planning actually means, what it consists of, and the best way of hosting it for a great outcome.

If you are interested in more Scrum articles, make sure to check out the Bordio blog which is updated every week.

What is a sprint planning meeting?

A sprint planning meeting is one of the main Scrum events, also known as ceremonies, that is scheduled in the team’s online calendar at the beginning of each sprint. In fact, it is the starting point of the upcoming sprint.

A sprint, in turn, is a time period within a project that typically lasts 1 to 4 weeks. Within the given sprint, the development team and product owner, guided by Scrum Master, work to complete the set number of tasks and goals.

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. The Scrum team has to think through the complete to-do list and make sure the workload scheduled in free schedule planner for the sprint is both challenging and doable.

Because Scrum’s philosophy encourages regular releases of potentially shippable products (meaning that they can be used by the business, although in a limited fashion), one of the success factors of the sprint planning event is identifying the top priority tasks with all dependencies and focusing on them first.

The sprint planning meeting format and purpose

The sprint planning process is a collaborative effort and it needs to be attended by the product owner, the development team, and the Scrum Master.

The ceremony helps the whole group focus on execution, minimize surprises, and get higher-quality outcomes.

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. There is no minimum length, so if the product owner and the team reach an agreement and finish earlier, they are free to close off and get to work. The method will be easier if you use the best time management tools.

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. Also good way is to use tools for project management. And you can use remote work collaboration tools to control remote workers.

The sprint planning agenda

Sprint planning agenda is fluent and flexible to a degree. However, there are 2 main questions that have to be answered to have a successful sprint planning meeting:

• What can we deliver to meet the goal (the sprint goal)?
• How will we deliver it (the sprint plan)?

If the Scrum team decides to formally divide their sprint planning into 2 parts in accordance with those questions, they can do that. That way, the first part of sprint planning is about scoping, and the second part is for the actual planning.

Tip: Remember that during the meeting, and throughout the Scrum project in general, everyone is equal and should share their thoughts and opinions freely. Have them write down their thoughts ahead of time in their simple daily schedule planner. Every member of the development team can bring in a new perspective and invaluable insight that will lead the project to greatness. It will be much easier to work in a team with convenient tools for managing remote employees. Teamwork will be easier with special remote work management tools.

An alternative way to divide the meeting into subcategories is by splitting the agenda into 5 elements: what, how, who, input, output.

1. What is the goal of the sprint?
2. How will the goal be achieved?
3. Who is working on what?
4. Input that we have at the starting point.
5. Output of the sprint.

Don’t forget to describe the questions in the schedule planner online.

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.

Working with the sprint backlog items

During the sprint planning meeting, the Scrum team and the product owner sit down and review what’s in the backlog to see if something needs to be:

• Added
• Changed
• Removed

Why? As the project goes, requirements change, new opportunities come up, risks occur, stakeholders get new ideas. And if our backlog is not up to date, then the team risks wasting time on features and tools that have no use or will have to be re-done to meet the new requirements.

Backlog refinement is a separate Scrum ceremony. So while we can and should review the backlog during the sprint planning, we should not dedicate too much time to it.

Most Scrum experts recommend either running a backlog refinement session prior to the upcoming sprint start or after the sprint planning session. The meeting has no particular place in the schedule and should be held and repeated on demand.

Tip: To learn more about the rest of Scrum ceremonies, check out Bordio’s articles on sprint review, sprint retrospective, and daily standup.

Estimation in sprint planning meetings

Estimation attracts a lot of attention is the sprint planning meeting agenda. We work on identifying how much capacity we have and how much time the user stories will take to complete.

Estimating in Scrum projects means roughly calculating how much time and resources the user story would consume from the beginning to the done-done stage. It is an educated guess but deviations are inevitable. To help us make the most data-based estimation the teams use information from stakeholders and documents and reports in the company on the past experiences.

Why estimate?

Estimation takes time and effort, so people sometimes disregard it. Estimation should not be downplayed though, and here are the top-3 reasons why every Scrum project has to allocate time for it:

• Without estimation, we will not have an idea about the suggested duration of work, the sprint, and the project as a whole. As the project is time-bound and a shippable increment is expected at the end of the sprint, estimation allows the team to fill in their daily planner app adequately, fulfill their obligations and keep their stakeholders happy. They can use free schedule maker for that.
• It allows us to qualify and clarify the user stories that we are intending to work on. Dropping the big tasks down into smaller ones, identifying dependencies, – all that makes us more aware of the actual job.
• Estimation highlights complex and high-risk tasks. As we work out how much time and energy something should take, we inevitably look into details of it and spot any risks or tricky moments that each task contains. With that knowledge, we can create a plan B, mitigate most risks before we actually start, and avoid snowballing issues later in the project.

Estimating team capacity in hours

Calculate how many people there are on the team and multiply it by their normal workload. You can check this through the group schedule builder app.

Let’s say your team is 10 people and they work on the project 5 days a week 4 hours each day. It means that in total you have 200 hours a week.

Next, we take the 400 hours (for a two-week sprint) and deduct all the hours spent on meetings and calls. Let’s say after that we end up with 300 hours. This number represents a 100% productive work time which, again, will be lower due to lunches, coffee breaks, random chats.

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.

Because Scrum focuses on effort and being efficient, rather than stressing about the number of hours that were invested in the project, alternative estimation methods have become popular and overshadowed calculating the effort in hours.

Popular estimation techniques in Scrum

There are many estimation techniques out there that help estimate the effort required to complete the user stories. Today we will touch on the 3 most common ones:

• Big/Uncertain/Small (aka BUS)
• T-shirt sizes
• Fibonacci sequence

Big/uncertain/small (BUS)

Here, we categorize user stories into 3 groups: big, uncertain, and small. To do that, compare each user story to others and assign it to one of the three groups.

Any big stories should be broken up into smaller ones if possible. Uncertain stories must be groomed or broken up.

Some stories will stay big and that’s fine as long as they’re not the majority.

T-shirt sizes

This estimation technique categorizes user stories into t-shirt sizes: XS, S, M, L, and XL. Here too, each user story is compared to others but they are assigned sizes.

The benefit of this technique is that it’s very universal and globally understood, making it fit for international teams.

While L and XL stories can stay in your sprint backlog, it’s advised to break as many up as possible.

Fibonacci sequence

This is the most complex estimation method, so it’s not as widespread as the other two.

Here, we cross-compare user stories and use abstract numbers to group them. Those numbers are called story points. The sequence goes like this: 1,2,3,5,8,13,21.. making it into groups like this: group 1 +2 =3, group 2 +3 = 5, etc.

The total number of story points per sprint equals team velocity.

Benefits of the sprint planning meeting

Now that we’ve talked about what a sprint planning meeting is and what it consists of, let’s move on and discuss why it’s actually beneficial in terms of project management.

• Helps team members agree on the goals and commitments before the active work starts.
• Allows to properly select a list of tasks, identify dependencies, prioritize them, and estimate the workload.
• Serves as a space to come together and exercise team spirit and teamwork.
• It is cost-saving: taking time to plan saves money and time that will otherwise be spent on having to re-do the work.
• By the end of the meeting, the team walks away with a group consensus of their work scope for the upcoming sprint and an estimation of how they will get on with that work.

Set your sprint planning meeting for a success

In order to have a good planning event, we need a bit of preparation and discipline.

1. Remember the previous planning sessions, learn from the mistakes and implement the good parts.
2. Make sure the product backlog is up to date. One of the Scrum ceremonies is backlog refinement or backlog grooming which is a dedicated meeting for exactly that. If the backlog is not optimized, it will affect the sprint backlog negatively, create confusion, delays, and annoyance.
3. Focus on the results of the sprints and not the nuances of who will do what work. That’ll give you the strategic view and perspective which will help get to the best result. It’s the valuable outcome that matters the most.
4. Embrace the fact that you can plan and estimate, but the reality will come in the way no matter how good you have it figured out. And that’s okay! Scrum treats change as a good thing, and so should you.
5. Last but not least, good planning happens in environments where people trust each other and can share their opinions honestly without the fear of being ridiculed. Make sure to set the right tone and brief the entire team on the behavioral guidelines. You might not come across such issues if you work with mature teams but it makes sense to talk this through in any case.

During the meeting, the team and product owner can discuss their definition of done (DOD).

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.

Key takeaways on sprint planning

The sprint planning meeting is a vital part of the Scrum framework and Agile methodology that helps the Scrum team have a focused and productive process that generates the best results.

Sprint planning helps move the product development forward and reach every sprint goal. It allows the development team to work with the backlog efficiently and not make it into a huge mess with an endless list of to-dos and no strategic thinking involved.

At the end of the sprint planning session, the team needs to have a clear understanding of the three things:

• What is the expected value(=sprint goal) of the upcoming sprint?
• What can be done within the new sprint?
• How will the selected tasks be executed?
• Sprint planning will get better with time. It’s fine if not everything goes perfectly. Just strive to make your next sprint planning meeting better than the previous sprint planning.

To help your team manage upcoming sprints better, make sure they learn about new time management skills and productivity tips to help them achieve more with the scarce time they have.