Product Owner Checklist for the Sprint Planning

Product Owner’s primary responsibility is to carry the product vision to implementation. Sprint planning is the Scrum ceremony where the team plans and commits on what they will achieve in the next sprint. As a Product Owner, your main objective is to propose the future sprint backlog.

Below is a checklist that you can use as PO to prepare for the Sprint Planning:

1. Prepare an overview of the stakeholders’ benefits
2. Share the release roadmap and the current situation.
3. Be ready to share with the scrum team the upcoming milestones
4. Select the user stories proposed for the next sprint.
5. Order the user stories based on the business value
6. Review all the user stories to make sure they have all the information: description, acceptance criteria, links to the right parent (feature), story points, links to the connected user stories.
7. Review the Definition Of Ready (DOR) and make sure the user stories you selected for the next sprint are all meeting it
8. Identify top priority user stories that aren’t ready (they don’t meet the team’s definition of ready) — this is not a good practice, but exceptions arrive. They need to be estimated by the team quickly. In consequence, you need to prepare clear and complete information for these user stories.
9. Upload all the assets the team needs for each user story: data examples, access to different systems, the right contact persons.
10. Anticipate questions the team might have and add the answers in the description of the user stories.
11. Slice the user stories if needed, here you can inspire on how split the user stories.
12. Define the sprint goal together with the rest of the scrum team
13. Prepare the agenda of the sprint review — this is a good practice to define a valuable sprint goal and focus on customer value.
14. Reorder the user stories if needed. For it will, you’ll need to know very clearly the value provided by each user story.
15. Support the team to define the tasks of the user stories.
16. Share your schedule for when you can spend time with the team during the sprint for further clarifications or PO acceptance of the user stories
17. Balance the sprint between maintenance user stories, technical improvements, and spikes. Learn more about spikes on How Spikes help to Improve your Agile Product Delivery.
18. Understand team velocity. With the help of the scrum master, you will know the team velocity and if there is room to improve it. The main take when it is about velocity is that you care about a constant pace rather than continuous growth.
19. Prepare user stories that match the velocity. There are three schools on defining the sprint load: underload, overload, and load, just the right amount of user stories. Scrum recommends underload, so when the team finishes the user stories planned for the sprint, they’ll pick up more user stories from the top of the backlog. Out of over ten years of experience, I can tell you that rarely happens.

The second option is to overload — add more user stories than the capacity of the team. I strongly recommend this technique to new teams. It is a forced way of discovering what the upper limit of the team pace is. After 4–5 sprints, this technique will not work because it is very demotivating for the team never to reach the target. If, as a Product Owner, you continue to overload the sprint, you’ll end up with user stories not finished and with an unreliable velocity. Remember: your target is predictability.

The third option is loading the right amount of user stories. But how do you know what is the right amount? Using option 2 for about 3–4 for sprints, will give you a good idea of what is the velocity of the team. Then you’ll agree with the team that that will be the target you must achieve.

What is your Sprint Planning checklist as a Product Owner?