In my previous blog post I talked about how to create a Product Backlog from scratch. We looked at an example product – online education hub about Scrum – and used a real online tool for Product Backlog management called ZenHub.
Ok, so now we have our Product Backlog started with some functional and non-functional requirements identified. Next step is to actually start our first Sprint!
Let’s do the first Sprint Planning ever.
In this video I will show you an example planning using the Product Backlog I created last time. Watch the video to learn how you can do it in ZenHub (which should be easily transferable to any other platform you use).

Get the best out of your Sprint events
In my ultimate guide for Scrum Masters, I give you concrete examples and tools for running Sprint Events like Sprint Planning.
What to consider in Sprint Planning?
When you go into your Sprint planning there are a few things you should consider. I don’t go in too much detail about it in the video, so here are a few more insights for you:
- Definition of Done (DoD). When it is clear what is considered ‘Done’ the team has a better understanding of all the different types of tasks they generally need to complete apart from pure development. E.g. testing, documentation, integration, code review, etc. If you don’t have a DoD yet, you should spend some time creating one.
- Capacity of the team. Discuss anything that might reduce the team’s capacity, like days off, holidays, other events, or other commitments.
- Velocity. If you are measuring velocity using story points, for example, you can use your past data to help understand how much work the team can realistically take into the Sprint.
- Sprint Goal. This is number one topic that needs to be discussed in a Sprint Planning. A clearly stated Sprint Goal will help the team select the right Product Backlog items to align with it.
- Acceptance criteria of Product Backlog items. Obviously, the team will need to have a good understanding of what is required for each work item they want to select into their Sprint Backlog.
There is a guide for that
As I was writing this blog post, I realized that I have lots of various guides that touch up on the topics mentioned here. Instead of polluting the blog post with links, I decided to just list all of the guides relevant to what I mentioned above right here in a list:
- Creating the Definition of Done
- Introduction to relative agile estimation
- Measuring team performance
- Creating good Product & Sprint Goals
And if you want even more specific information about every Sprint Event, I encourage you to check out the Scrum Master Startup Guide.