Spring Planning is an integral part of setting your team up for a successful Sprint. Without the appropriate amount of work and understanding of the goals, a Sprint can quickly derail, and your team can lose focus. Luckily, these meetings are fairly easy to master once you’ve perfected a few key planning processes.
If you’ve never run a Sprint Planing meeting, here’s your go-to guide.
Selecting items off the Backlog
At the beginning of each Sprint, the Product Owner, Scrum Team, and Scrum Master get together to organize the workload that will be done during the upcoming Sprint.
First things first, everyone reviews the Product Backlog with the Product Owner providing insight into the goals and context for each item.
Next, the Scrum Team selects the number of 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 according to the Product Owner, the Scrum Team must choose items from the top of the Backlog.
This dynamic is what 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. Items are never “assigned” by the Product Owner or Scrum Master while work is always being pulled in order of importance. It’s up to the Scrum Master to facilitate the process and maintain this balance of powers.
Not only does this ensure that each member of the team feels empowered in regards to their own work, but it also ensures a more sincere commitment and greater accountability from the team since they are the ones choosing to do it.
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, so 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
Estimating time to complete each Backlog item
The second piece of the puzzle is figuring out how much time each item on the Backlog itself will take. This requires the Product Owner and team to work together to break the item down into individual tasks which 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 are recorded in a document called the Sprint Backlog, i.e. a version of the Backlog that is relevant only to the current Sprint.
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.
Again, 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.
By the end of the meeting, the Sprint Backlog will contain a list of each task, how long they will take, and who is assigned to them.
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 and think through every item before pushing it 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 Backlog are free to be made before the start of the next Sprint, giving the Product Owner free reign to make any additions, deletions, or modifications necessary promptly.
Change then becomes an accounted for part of the process and is no longer viewed as a cause of stress or reason for missing deadlines.
The Sprint Planning meeting will often last a couple of hours when run correctly. The commitments put forth require careful thought and deliberation, and 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!
Searching for the right project management tool?
Check out Backlog, a project management tool for developers and their teams.