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”.
· 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.
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.”
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.
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.
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.
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:
T-Shirt Sizing | XS | S | M | M+ | L | XL | XXL | XXXL |
Story Points | 1 | 2 | 3 | 5 | 8 | 13 | 20 | 40 |
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.
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.
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:
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.
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.