Sprint Planning Meeting
TOPICS COVERED IN THIS GUIDE:
- What is a Sprint Planning Meeting?
- Who should attend a Sprint Planning Meeting?
- How long should a Sprint Planning Meeting last?
- Best practices on how to run an effective Sprint Planning Meeting
- Quick Summary
What is a Sprint Planning Meeting?
A sprint planning meeting happens before a Sprint begins. The entire scrum team come together during this meeting, discuss, and agree on what they’ll deliver in the upcoming sprint.
During the sprint planning meeting, the product owner explains the highest priorities, helps the development team understand why the user stories are important, and how they’ll impact users.
With this knowledge, the development team asks questions to get a better understanding of the users needs, and try to break down the user story into actionable pieces of work with an estimate on how long it’d take to build it.
In short, the main goal of the sprint planning meeting is to walk away with two things:
Sprint goal: Agree on what will be delivered at the end of the sprint.
Sprint backlog: A prioritized set of user stories, enhancements, bugs, tasks, and sub-tasks for the up-coming sprint that will help the team focus and deliver.
Who should attend a Sprint Planning Meeting?
All members of the sprint should attend the sprint planning meeting. That is:
- The Product Owner
- The Scrum Master
- The Development Team
When you’re discussing to agree on what everyone will deliver at the end of the sprint, it’s best to get everyone’s input and perspective before you move forward. After all, you wouldn’t want to miss any edge cases.
How long should a Sprint Planning Meeting last?
According to Scrum Guide, the sprint planning meeting is time-boxed to eight hours for a one month sprint. If your sprint is shorter than a month, sprint planning meeting is reduced proportionately.
For example, a two-week sprint should not have a sprint planning meeting that exceeds four hours.
But does that mean you must spend eight hours planning for a month-long sprint?
If a meeting concludes before the time allotted, end the meeting and leave! Don’t try to fill the time with other random top of mind topics. ~ Paul Adams, VP of Product at Intercom
As long as your team is on the same page on what will be delivered in the upcoming sprint, it’s alright if your meeting ends in an hour. Remember, principles support your business. You shouldn’t mould your business around them.
Best practices on how to run an effective Sprint Planning Meeting
1. Bring your learnings from the previous Sprint: If you ran a sprint prior to the one you are currently planning, you most likely found areas you’d like to improve by running Sprint Retrospective Meeting. Be sure to bring it up during the sprint planning meeting and see how you can implement changes to your upcoming Sprint to improve your process.
2. Have a groomed backlog:
Before the sprint planning meeting, make sure the backlog is groomed with fully formed user stories and the most important work listed at the top. It’s best done a few days before the sprint planning meeting with just the product owner and the scrum master.
If you’re using Zepel, you can quickly add more details to your user story by adding detailed description, attachments, and comments. That way, every member has the full picture of what each user story tries to achieve and everyone is on the same page.
This allows the product owner and scrum master to fill details and context to user stories that might not be fully formed and come prepared for the sprint planning meeting.
3. Tell a story:
As a product owner keeping in mind that each backlog item is a user story and not a bunch of features could make a world of difference, especially when you’re trying to explain it to your development team.
Showing your dev team where the problem occurs in the user’s current solution and why it’s a pain will help them get a clear picture of what they need to be working on.
After all, the sprint planning meeting is a way for the product owner to convince the rest of the team on what the highest priorities are. And what better way to convince people than telling a story?
4. Drill down to the details:
When you drill down to the details of a user story by breaking it down to tasks and subtasks, the entire team gets an idea of the complexity involved in building it. Besides, breaking down a large chunk of work into tiny pieces of actionable work makes estimating your work much more easier.
When you haven’t thought about what you’re going to do, you can’t know how long it will take. ~ Joel Spolsky, CEO of Stack Overflow
5. Get approval and align everyone on the same page: Once your development team breaks your user stories down to tasks and subtasks, and you have an estimate of how long each of them will take, you should ideally be able to come up with a Sprint backlog that you can add to a Sprint.
Be sure to add each work item to a Sprint on your project management tool and ensure each member has at least one item to work on and nobody is duplicating work. Once you’ve added items into a Sprint, be sure to reiterate the goal for the Sprint and show your team the list of work items the team will be working on.
In Zepel, once you’ve added items into a Sprint, set a start and an end date for your Sprint based on the total estimate. This will ensure that everyone can see how the sprint is progressing and know who is responsible for what.