If you can nail your first sprint planning meeting, you’re already halfway towards reaching your sprint goal. Feeling nervous? Don’t be, this article is here to help you.
Read on, and you’re sure to run your first-ever sprint planning meeting like a pro.
Table of Contents
There’s a real risk key players might be unavailable at the time of your choosing.
Bug and crash reporting tool for your mobile app.
This app will automatically inform you if there’s a conflict, as shown below:
This feature is invaluable for choosing a meeting time.
If you’re planning a two-week sprint, the meeting shouldn’t last more than four hours. With that in mind, set aside half of the workday to hash out all of the details with your team.
Story points indicate how difficult you expect assignments to be and are ranked based on these characteristics:
If all of your tasks end up in the double digits, it might be a good idea to cut down or switch them out for simpler ones.
Present the sprint goal
After you’ve prepared everything, it’s time to begin the meeting itself.
One Reddit user commented on the importance of this:
You might even devise alternatives that make certain backlog items redundant.
In that scenario, you can easily remove backlog items such as implement a sequence that utilizes the full LED spectrum or introduce a program that lasts over 90 seconds.
With the new manual set-up, you won’t have to worry about the countless possible automatic configurations.
To draw on from the previous example, a SMART goal would be:
“In one month, release manual controls for the full LED spectrum in our app-paired devices for a better user experience.”
This SMART goal has an exact time definition, is extremely specific, and is attainable.
Discuss product backlog items
Given its large scope, it’s essential to prioritize and choose the items your team aims to complete during the sprint.
Here’s an example of a standard product backlog:
For instance, changing one’s username on their own is nowhere near as important as having a search function.
After you’ve agreed on which features to focus on, those items are moved from the product backlog into the sprint backlog.
The graph below outlines the differences between the two:
This helps your team decide on their tasks for that sprint.
Every time you’re thinking of adding an item to the product backlog, take a moment to assess if that item contributes toward the DEEP principle.
Have you assigned the story points? How high of a priority is it?
Answer these questions before blindly posting new items.
Upholding a DEEP backlog will significantly facilitate your backlog discussions as the backlog itself gains quality.
This can be done two or three days before the end of the sprint or during the sprint planning meeting itself, but ensure you continuously refine the backlog—it’ll make future planning much more manageable.
Estimate team velocity
This metric is one of the most critical measurements in sprint planning, as it determines how much work your team will be able to accomplish during the sprint.
Team velocity will be challenging to determine for your first sprint, as it’s best calculated once your team has gone through multiple sprints.
For example, imagine that in the first sprint, your team completed 25 story points, 30 in the second, and 35 in the third. The velocity is then calculated as:
It’s also a fantastic guide for the product backlog, as it helps determine how many items to pick up.
In other words, don’t give up if you’re disheartened at the beginning. Stick with the practice—it will eventually pay off.
Velocity often improves based purely on your developers’ affinity with one another and can’t be decided based on technical knowledge or years of experience.
If you want foolproof data on this rhythm, online tools can help you keep track of velocity.
Here’s the chart below:
The chart is fantastic for displaying how well your team keeps up with their commitments.
Determine task ownership
- To Do—the backlog items planned for the sprint
- In Progress—the items that you’ve started working on
- In Reviews—items that are being tested and reviewed
- Done—completed and verified items
Here’s an example Scrum Board:
This resource gives you a clear overview of who’s on top of what.
The visual below explains the concept well:
For example, imagine if your sprint backlog item was allow users to update shipping information.
The more detail you provide, the more direction you give your developers, and the better they can gauge which tasks to take on.
This Reddit user offers an example of this:
In keeping with this example, imagine presenting this task to your employees.
On the other hand, if you had simply delegated the entire improve data model item, you’d have more difficulty choosing the right person.
That way, they can assess whether their tasks are achievable with a level head.
If it turns out that they’d rather not take on an assignment, or if they feel out of their depth, there’s nothing to worry about. It’s still the beginning of the sprint, and you’ll have plenty of time to reorganize.
Your first-ever sprint planning meeting is an important milestone for the sprint and your career. If you pull off a quality planning meeting, you’ve already done half the sprint work.
Ensure you come well-prepared to the meeting, and have a clear sprint goal to present to your developers.
Go over the product backlog items, and estimate your team’s velocity. Evaluate how many items they’ll accomplish.
Finally, break down those items into tasks, and distribute them to the most capable team members.
Follow these five practices, and you can’t go wrong—your sprint planning meeting will go off without a hitch.