Running your first Sprint Planning meeting

The Scrum framework of project management is based on four basic 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 that they want to commit to completing by the end of the Sprint. Because the Backlog is organized in order of importance, the Scrum Team must choose items from the top of the Backlog.

This dynamic creates a balance between Scrum Team and 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 regards 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 pull items from further down the Backlog only if it makes more sense given the other work being completed that Sprint. Meaning, if the work will logically get done faster because it is very similar to other items.

Estimating 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 4-6 hours of time per day available for Sprint work.

Estimating 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. Those tasks can then be assigned 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, i.e. 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. Sequencing and other factors may determine that it makes more sense for one person to get a certain grouping of items, but tasks are never assigned against the will of the worker.

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. Basic categories like To Do, In Progress, Code Review, and Done can help the entire team get an overhead view of how the Sprint in progressing.

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.

The only exception would be if an external factor were to change priorities so drastically that the team’s efforts would be wasted 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. A disruption of this kind should be a big disincentive for the Product Owner who should only resort to it 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 where team members 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, the main Backlog can be changed at any time. The Product Owner has free reign to make any additions, deletions, or modifications necessary before the next Sprint.

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

Final Thoughts

The Sprint Planning meeting will often last a couple of hours when run correctly. The commitments put forth require careful thought and deliberation. You should allow your team the time it needs to thoroughly plan for success.

What are your favorite tips for running a successful Sprint Planning meeting? Let us know on Twitter!

Try Backlog for 30 days.

Join 800,000 developers running on Backlog. No credit card required.

Try It Free