Here's something our team is focused on improving on right now
Optimizing sprint planning is essential for success
Let’s face it — not everyone loves sitting in a bunch of meetings all day. But sometimes, live collaboration on a call is just the only way to get aligned and keep the ball rolling.
PMs are subject to tons of meetings as well, including sprint ceremonies. All teams that strive to operate in an agile scrum environment have meetings where the focus is on sprints, which are essentially small periods of time where engineering works on items that are agreed upon and prioritized by the PM. It’s important every product development team figures out meeting structures and cadences that work best for them.
Recently, my team has been making a greater effort to really dive into the weeds on sprint planning sessions. It is reasonable to assume that certain aspects of work aren’t really uncovered (including obstacles) until you actually start working on it. However, as many unknowns, complexities, and questions as possible should be discussed in advance of the sprint starting. That is my team’s agreed upon goal of sprint planning. We believe if we accomplish this goal, then our say:do ratio will be high, our velocity will be predictable (and thus, the roadmap more accurate), the quality of work will be excellent, and the amount of back and forth during a sprint is minimized.
According to Scrum Alliance (see link above), here is what happens during sprint planning:
"During sprint planning, the entire Scrum team collaborates and discusses the desired high-priority work for the sprint and defines the sprint goal. The Scrum Master’s role is primarily to facilitate the meeting. The Product Owner describes the objective of the sprint and also answers questions from the development team about execution and acceptance criteria/criteria of satisfaction. The development team has the final say in how much of the high-priority work it can accomplish during the sprint.”
In advance of sprint planning, I do everything I can as the PM to ensure user stories (outlined in Jira cards) are detailed, yet concise. We review the stories as a team. Engineering will review them during sprint planning and ask clarifying questions. Where it is my role to have user stories and priorities defined, it is engineering’s responsibility to ensure they know what to do before it is actually time to do it. Key dependencies and technical complexities are all discussed during sprint planning. In many ways, your sprint will be as successful as your sprint planning sessions!