If sprint planning takes three hours, the problem isn't the meeting — it's that prioritization didn't happen before the meeting started. A 30-minute sprint planning session isn't a faster version of a 3-hour one; it's what's left once you remove the parts that shouldn't have been live discussion in the first place.
Most of the time goes to work that should already be done
Long sprint planning meetings are usually long because the team is debating priority order, re-estimating tasks from scratch, and discovering that half the backlog isn't actually ready to be worked on — all in real time, with everyone present. Each of those is a separate piece of prep work, and none of them require the whole team in the room simultaneously.
Groom the backlog before the meeting, not during it
If the top 10–15 items in the backlog aren't already estimated, clarified, and ordered before sprint planning starts, the meeting will spend its first hour doing that work live. Backlog grooming is cheaper done asynchronously, in smaller chunks, by whoever owns the backlog — sprint planning should start from a list that's already in shape, not from a pile.
Decide capacity before the meeting, decide commitment in it
How much the team can realistically take on is a calculation, not a debate — known velocity, known time off, known interruptions. Working that out live wastes the room's time on arithmetic. What the meeting is actually for is the team looking at the top of the groomed backlog and saying "yes, we can commit to this" — a short conversation if everything before it was done properly.
What 30 minutes should actually contain
Confirm capacity (2 minutes), walk the top of the backlog and pull items in until capacity is hit (15–20 minutes), flag any last-minute blockers or questions (5–10 minutes). If a task needs real debate about scope or approach, that's a sign it wasn't ready for planning — pull it out and groom it properly before the next sprint, rather than letting it eat the room's time now.