Planning your first sprint can be challenging, but it doesn’t have to be. There are a few things that the team can do to prepare for the sprint planning session to zero in on an achievable amount of work that the team can agree to. As is the case with most things, good preparation is the key.
In order to properly prepare to plan your first sprint, there are a few things that I recommend that you tackle before starting to plan the sprint:
- Established an overall plan with your product roadmap.
- Break the first portion of that roadmap down into multiple items and prioritized them in your product backlog, perhaps through a Design Thinking Workshop.
- Established what a Minimal Viable Product (MVP) might look like through a story mapping exercise.
- Go through Sprint 0 with the team to discuss backlog items and size as many as possible with story points
Done with that? Great! Now you’re ready to plan Sprint 1!
Typically during a sprint planning session, the two items that are used to determine a sprint workload are story points and average velocity. We have the former with our sized product backlog, but during the first sprint, we’re missing the latter. Average velocity can only be established after one or more sprints have been completed, so what do we do for Sprint 1? The answer is to task the stories and estimate the hours needed to complete them.
By estimating all of the tasks needed to complete a story in hours, the team can determine if they have more capacity and the ability to bring in more work. Once the team has added in the hour estimates for all the tasks that they believe they can complete within the iteration, they now can agree on the first increment of work to be delivered.
Every time we iterate in Scrum, we inspect and adapt. After completing Sprint 1, the team now has an initial velocity benchmark to utilize in planning Sprint 2, Sprint 3, and beyond. However, even with an average velocity established, I still recommend that the team tasks the stories and estimates the hours needed to complete them, just to be sure that none of the team members are over/underloaded during a sprint.
Have any questions? We’d love to work with you to help solve your next SAP problem with a proven Agile approach – please contact us to get started.
View our LinkedIn, here.