Sprint planning can be one of the longest, most painful parts of the Scrum process. I have been in planning meetings that take a full day and still end with many questions up in the air. It is terrible. But it doesn’t have to be.
Planning meetings have a singular purpose in my opinion: to define what the team is working on for the next sprint. Everything else is tangential. This is the real goal for me as product owner and development manager. Where does this information come from? The product backlog.
Having a well defined product backlog with good user stories can make or break a planning session. All the other planning details your scrum-master might have aren’t nearly as important as a good product backlog.
Define stories, don’t create them. If your planning meetings involve stakeholders continually modifying the product backlog during the planning, the product owner has failed. The stakeholders are there to help define the details of the story, not create new ones.
Have the right priorities. Nothing is worse than attending a sprint planning where priorities have changed since the last time the backlog was updated. Priorities and the backlog need to be updated continually so a sprint planning works with the latest, and most valid information.
Define stories just enough before planning. The product owner shouldn’t spend hours creating requirements documents. Instead, the team should just have a conversation regarding what the details of the story really are during planning. On the flip side, they must be defined well enough for the team to ask questions. Make notes better is a terrible backlog item because it has no clear goal.
I have been guilty of violating all of the above tips, but these are just a few of the things I have learned that help make product backlogs more useful and make sprint planing meetings go smoother.
