The sprint planning session is one of the key activities to ensure a successful execution of your Agile projects. If done correctly, it will help ensure you have the commitment and buy-in from each team member to deliver the content to the best of their ability. The sprint planning session is a collaborative meeting in which the team estimates the size of user stories, breaks down stories into tasks and commits to deliver the stories during a sprint as per the pre-determined and agreed upon “definition of done”.
What you will need:
- Allotment time of 2-4 hours depending on the team and complexity of the sprint
- An office large enough to accommodate the entire team
- Visual workspace for a sticky note board (or have Yodiz setup for remote teams)
- Sticky notes in at least 3 different colors
- Light refreshments and/or coffee
Here are some tips to ensure you get the most out of your sprint planning session and execute your projects successfully.
1. Set the sprint goal
Ask the product owner to come up with the goal of the sprint. Here is an example of a sprint goal for a CRM system:
“Show the happy path to capture customer order with billing preferences.”
2. Prioritize the stories that fulfill the sprint goal
Once the goal is established, prioritize the stories that fulfill that goal. If you find your team has additional capacity available, then you can consider prioritizing additional stories that don’t necessarily complement the sprint goal.
3. Arrange an informal sprint planning preparation meeting
Before the actual sprint planning session, bring relevant team members up to speed on the expectations for the next sprint and which stories the business needs to be delivered. Use this as a sanity check to make sure stories planned are actually doable and don’t have any known hard blockers. You will find it helps reduce the number of surprises that might come up during the session.
4. Meeting arrangements
- Send the invite and make sure to have a video call setup if part of your team is remote.
- Print the sprint goal and put in somewhere prominent in the meeting room. Have different color sticky notes readily available.
- Write down the velocity of the team in bold letters. Write down the agreed reference velocity, which can be the last sprint velocity, or an average of the last 3 sprints. If it’s your team’s first sprint, you can use a reference velocity of 8 story points per developer per sprint.
- Make sure it’s clear what each color sticky represents. For example, green is for user stories, blue is for tasks and purple is for bugs.
- Arrange light refreshments or at least coffee, which is always appreciated.
- Have the stories written on the stickies and arrange on the wall in their priority order. For remote teams, be sure to do the same in either the sprint or backlog.
5. Introduction of the candidate stories
Let the product owner explain the purpose and details of each of the top stories that can be picked up in this sprint. If the team has any questions, this is the time to ask.
6. Sizing of the stories
Teams can do the sizing of the stories using techniques like Poker planning. If the team is not experienced in sizing stories, you can use the “T-Shirt” sizing method as a way to base estimates on the complexity of implementation. We recommend using the following T-shirt sizes for story point comparison:
Yodiz Tip: Use actual story points when using Yodiz, but T-Shirt sizing is a good way to educate your team on how to estimate stories.
7. Breakdown stories into tasks
Make sure the team has broken down the stories into tasks, as this will help the team think about everything that needs to be done to complete the stories. It’s also good practice to create Testing as a separate task. When estimating tasks, some find it helpful to estimate tasks in hours, as it’s easier for teams and individuals to do their own tracking.
8. Agreement on the bug fixes and support work
Agree on the percentage of the capacity that will be used for bug fixes and support work, if any. There are several ways to account for this:
- Use a fixed capacity, such as 20%, for bug fixes and other support work.
- Have the bugs linked to a user story and then size the story with bug fixes included, so there is no fixed reserved capacity.
- Make sure the user story “definition of done” includes testing and bug fixes, as this helps deliver better quality software at the end of each sprint.
9. Setting due dates
It’s very helpful to rough plan when each story will tentatively be done. Using due dates is good mechanism to drive and track progress and it’s especially useful for testing and external stakeholder communications.
Yodiz Tip: At this stage, it’s helpful to use the Yodiz calendar to set the due dates for each task and user story. This will allow you to visually map out which story will be completed on which day. Depending on your approach, these dates can be viewed as aspirational and not actual “due dates.” You can learn more on how to use the Yodiz calendar here.
10. Effective work days
To calculate the potential impact on sprint velocity, be sure to record the team’s days off, holidays or any other events that could affect the sprint delivery.
- Agreed Sprint Goal
- Committed sprint backlog with stories and the sum of the story points isn’t more than the velocity
- Bug fixing and support work is included in the sprint backlog and isn’t more than the agreed capacity
- Each story is divided into tasks and each task has estimated hours
- Total number of estimated tasks isn’t more than the team’s actual capacity
- Tasks and user stories are mapped out in the Yodiz Calendar with due dates