To stay organized and on the same page, the product owner and development team should make continuous improvements to reprioritize, add new details, remove items, and adjust estimates as the product moves through evaluation and iteration stages. The backlog sets the stage for each sprint and for the product or software overall, so itâs important that Scrum teams have an up-to-date backlog so both parties know whatâs in the queue and what the capacity of the developers are.
You may even choose to hold a pre-planning meeting to prep the backlog and decide what work to complete during the upcoming sprint. This meeting wonât require the attendance of the full development team, only the Scrum master and the product owner. The more youâre able to prep your backlog before your sprint planning meeting, the better youâll be able to utilize the precious time allotted to planning your sprint.Â
Examine team availability
Before fully committing to a sprint schedule, make sure to address your teamâs capacity to complete the proposed workload. Ask team members to confirm any planned vacation time, commitments to other projects, and other possible time restraints. If team members canât fully commit to the sprint workload, adjust the workload accordingly.Â
Along with team availability, youâll also need to ensure that all of your necessary resources are available. Any known issues or setbacks should be factored into Agile sprint planning and addressed with the team before the sprint begins.
Establish velocity for your team
A teamâs velocity is equal to the amount of work that a team is able to complete in one sprint. Thereâs no set standard for how much your team should complete in any given sprint. Your velocity will depend heavily on how long your team has worked together, how many backlog items have been prepped to complete, and how effectively youâve planned your sprint.Â
If youâre trying to determine the velocity for a newly established team, track your teamâs deliverables and story points from sprint to sprint to gauge how much can be expected from your sprint team.Â
Plan your sprint planning meeting
The Scrum master should take care of the who, what, when, and where of the sprint planning meeting. This preparation includes deciding on the meetingâs date and time, as well as its attendees.
To determine the length of your meeting, first consider the length of your sprint. Multiply the number of weeks in your sprint by two hoursâthis should provide you with a rough estimate of how much time youâll need for your sprint planning session. For instance, a two-week sprint will require around four hours for a thorough sprint planning meeting.
Most importantly, the Scrum master should determine the sprint planning meeting agenda and distribute it to Scrum team members, the product owner, and other key stakeholders.
Best practices for running a sprint planning meeting
Your Scrum sprint planning offers a crucial time to plan and collaborate as a Scrum team. It can also set the tone for your upcoming sprint and provide a universal understanding regarding your sprint goals. The sprint planning session should be used to acknowledge your teamâs progress, articulate aspirations, and make concrete plans.Â
Follow these steps to ensure that your sprint planning meeting is an effective beginning to your sprint.
1. Start with the big picture
Begin your sprint meeting by officially ending your previous sprint and acknowledging team progress. Set the stage for your upcoming sprint by reminding your team of the overarching vision for your project and encouraging a positive, enthusiastic outlook on whatâs to come.Â
Any specific goals you have for your next sprint should be expressly stated at the beginning of the meeting, so you and your team can reference them when making concrete plans.Â
2. Present new updates, feedback, and issue
Once the vision for your upcoming sprint has been clearly stated, the Scrum master and product owner should relay any updates or new details theyâve received from stakeholders. You can also discuss feedback from the customer to provide your team with context and guidelines for the work ahead.Â
This is also an opportune time to go over any issues that might have impeded progress during the last sprint. Issues such as a lack of resources, poor communication, and other roadblocks should be addressed and discussed in a team setting in order to streamline future work.Â
3. Confirm team velocity and capacity
Confirm your teamâs availability for each stage of the project and make sure that your team is aware of the current velocity. Update your team on any newly added team members or shifts in responsibility that may have occurred since the last sprint.Â
Your goal should be to minimize surprises as you set deadlines and allow team members to select which stories to tackle over the course of the upcoming sprint.
4. Go over backlog items
Review your product ownerâs proposed backlog with your team. The backlog should typically include about two sprintsâ worth of work, which your team can organize and decide which items will be the main focus for the next sprint. Your discussion should allow team members to ask questions about backlog items and how theyâll relate to the upcoming sprint.
With an up-to-date product backlog, the team should agree on a clearly defined goal, the sprint backlog, and the expected outcome for the sprint. To help decide what is realistic within the sprint, you might refer to user flow diagrams or high-level UML diagrams to visualize how each item will fit into the overall product vision.
5. Determine task ownership
Review each backlog item with your team members and discuss who will own which tasks. Determine what each task will require, including resources and time constraints. Once you know what to work on, you can create a Scrum board or a swimlane diagram to delineate responsibilities and finalize sprint deadlines. Scrum masters should also define what each completed task should look like, so team members can accurately measure their progress.Â
This aspect of the meeting will require a fair amount of negotiation and collaboration, so the Scrum master should take care to watch the clock and keep discussions moving.Â