Running your first sprint planning meeting

The Scrum framework of project management is based on four basic Agile meetings, i.e., ceremonies: the Sprint Planning meeting, Daily Stand-up, Sprint Review, and Sprint Retrospective.

Spring Planning is an integral part of setting your team up for a successful Sprint. Without an appropriate amount of work and understanding of your goals, a Sprint can quickly derail. Luckily, these meetings are fairly easy to master once you’ve perfected a few key planning processes.

If you’ve never run a Sprint Planning meeting, here’s your go-to guide.

Selecting items from the Backlog

At the beginning of each Sprint, the Product Owner, Scrum Team, and Scrum Master get together to organize work for the upcoming Sprint.

First things first! Everyone reviews the Product Backlog while the Product Owner provides insight into the goals and context for each item.

Next, the Scrum Team selects however many items from the Product Backlog they want to complete during the Sprint. Because the Backlog items appear in order of importance, the Scrum Team must choose items from the top of the Backlog.

This dynamic creates a balance between the Scrum Team and the Product Owner. The Product Owner creates/organizes the Backlog and chooses what’s most important. But the Scrum Team decides exactly how much work they can commit to in a given Sprint. The Scrum Master facilitates this process and maintains the balance of powers.

This process ensures that each member of the team feels empowered in regard to their own work. In addition, it ensures a more sincere commitment and greater accountability from the team.

There is one exception to this rule: the team can only pull items from further down the Backlog if they make more sense with the other work in progress in that Sprint. This means that the work will logically get done faster because it is very similar to other items.

Estimating the availability of the team

Before selecting items from the Backlog, the team is also responsible for estimating how much time each member has for Sprint-related work. Most team members’ days will not be dedicated entirely to Sprint work. Available time should be determined by the average workday minus the time they expect to spend doing other work like maintenance, attending meetings, lunch breaks, email, and bug fixes.

Realistically, most people have four to six hours per day available for Sprint work.

Estimating the time to complete each Backlog item

The second piece of the puzzle is figuring out how much time each item itself will take. This requires the Product Owner and team to work together to break each item down into individual tasks. You can then assign those tasks an estimated time to complete. The time to complete all items selected for the Sprint cannot exceed the time available on the team.

Each task and time estimate is recorded in a document called the Sprint Backlog. This is a version of the Backlog that is relevant only to the current Sprint.

Self-organization

Once your team has finalized member availability as well as the time needed for each task, the team then begins determining who will complete each item by volunteering.

Items are never “assigned” to team members. Factors such as sequencing may mean it makes more sense for one person to get a certain grouping of items, but you never assign tasks against the worker’s will.

The final workload of each individual must be reasonable and fair. The Product Owner will play a huge part in helping the team fully understand each item so that they can break things up as evenly as possible.

Tracking progress

By the end of the meeting, the Sprint Backlog will contain a list of assigned tasks with time estimates.

Many teams use a Kanban board (either physical or digital) to visually track each item as it moves through the Sprint. Simple categories like To Do, In Progress, Code Review, and Done can help the team get a quick view of how Sprint items are progressing.

Other teams use dedicated project management software, which can help them track Sprints from start to finish with visual features like Gantt and Burndown charts. Task statuses like Open, In Progress, Resolved, and Closed keep progress transparent for all members. And tracking data like estimated time and actual time can help you better estimate work in the future.

During the Sprint

Once the Scrum Team commits and the Sprint begins, the Product Owner can not change requirements or add new requests. This person cannot make changes until the start of the next Sprint.

There is one clear exception to this rule: You can make changes mid-sprint if an external factor changes priorities so drastically that the results of the Sprint would be a waste if they continued. This rarely happens, but should it take place, the team would stop all work and start the Sprint Planning process over from scratch. The Product Owner should only resort to this massive disruption in extreme circumstances.

There are two positive effects of making the Sprints un-changeable. First, protecting the team from changes and additions mid-Sprint creates a more positive work environment. Team members will feel confident in their ability to complete their work and do it well.

Second, it encourages the Product Owner to prioritize their Backlog with utmost care. They are more likely to do their due diligence before pushing an item to the top of the list.

As time goes on, teams get better at estimating how long items take, foreseeing issues, and collaborating with one another. Using this structured Sprint Planning, Product Owners can be confident that their teams are both committed and able to do the work.

Adapting to changes

While Sprints should almost never be interrupted, this does not mean that change isn’t welcome within the Scrum framework. On the contrary, changes to the main Backlog can occur at any time. The Product Owner has free reign to make any additions, deletions, or modifications necessary before the next Sprint.

When teams approach change in this way, it becomes an accounted-for part of the process and is no longer viewed as a cause of stress or a reason for missing deadlines.

After the sprint

The Agile process is cyclical. However often you choose to run your spring planning meetings, you’ll always come back to them to start the process all over. The more often your team has gone through this, the smoother each cycle will be.

Besides completing the project or tasks at hand, your Sprint wasn’t entirely successful unless you learned something as a team from it. This next step of the process that you’ll move into is the Sprint Retrospective. It involved analysis of everything you just accomplished and what could go better next time. To get a leg up on some of the possible techniques you and your team can use, start studying before you finish your Sprint. A capable Scrum Master knows each step of the process exactly.

Final Thoughts

When run correctly, the sprint planning meeting will often last a couple of hours. The commitments made require careful thought and deliberation. You should allow your team the time it needs to thoroughly plan for success.

Keeping your tasks organized and transparent will make tracking the process much easier, so consider investing in dedicated project management software if your team isn’t already using it. Not only will a great project management tool save you time and effort, but it will also make it easier to glean insights from the process once you’re ready to dive into your Retrospective.

This post was originally published on January 11, 2017, and updated most recently on February 7, 2021.