Sprint Planning

A two-week sprint planning session should be 2–4 hours maximum. The structure in three parts: (1) Review — PM presents the prioritized sprint goals from the refined backlog, tying each item to a strategic objective. (2) Sizing & Commitment — Engineering estimates effort using story points or T-shirt sizing, identifies dependencies, and commits to a realistic sprint scope based on team velocity. (3) Task Breakdown — Selected user stories are decomposed into sub-tasks with assigned owners. Product Ops facilitates by ensuring all items have completed acceptance criteria, designs, and dependencies resolved before the ceremony — preventing the planning meeting from stalling on undefined work.

Sprint velocity is the average number of story points a team completes per sprint, calculated over a rolling window (typically 3–6 sprints). It is the primary capacity input for sprint planning — the team commits to a scope that does not exceed its historical average velocity. Product Ops tracks velocity trends over time, investigating anomalies (significant drops may indicate scope creep, tech debt, or morale issues; significant jumps may indicate under-estimation). Velocity is also used for release date forecasting — dividing total remaining backlog points by average velocity gives a predictive delivery window.

Product Ops is the enablement function that makes sprint planning efficient and reliable. Responsibilities include: maintaining a "sprint-ready" backlog (tickets drafted, acceptance criteria written, designs attached, dependencies documented), facilitating the ceremony and keeping time, maintaining the capacity tracker (accounting for PTO, interviews, and on-call rotation), documenting sprint goals and commitments, and following up post-sprint with a retrospective analysis comparing committed vs. completed work. Without Product Ops handling this overhead, Engineers and PMs spend planning meetings doing administrative work instead of strategic discussion.