All-hands planning meetings are probably a waste of time
Planning meetings are a strange beast. We get the team together and discuss the workload for the coming weeks. Sometimes, we estimate or reestimate stories, and people get to ask insightful questions. The team leaves the meeting envigorated to knock out some business value.
That's the theory.
In reality, planning meetings are a bore. The Product Owner reads the list of preselected tickets to the team, much like a lawyer reading a will to the bereaved. Team members wait until they hear their name or the topic they're interested in. The team leaves the meeting envigorated to finally get some lunch. And 10 minutes after that, the first request comes in.
"I have some questions about ticket ABC-123..."
All-hands planning meetings are an old-school artifact of Scrum. They are a vestigial organ from a time when teams were collocated, and meetings were the preferred communication tool. Getting all your developers in the same room to discuss the following week's scope is wildly inefficient.
In the typical team, developers aren't interested in every ticket. They are interested in a specific type of ticket: the one they will work on. The details and acceptance criteria are only interesting to those who will do the work. That makes sense. Family members don't care about the fine print of the zoning permit for that piece of land they won't inherit. Yet the lawyer keeps on reading...
All-hands planning meetings are strange in that they are both too long and too short at the same time. They waste a considerable amount of a developer's time, and when it finally comes to the ticket they're interested in, there's never room for deep discussion. "We only have two hours and still need to go through dozens of tickets."
The larger the team, the more waste.
There's only one scenario where all-hands planning meetings make sense: Focus Blocks. If the team will work together on a single problem, it makes sense to get them all together to discuss the solutions they will build shortly. The entire meeting will be of interest to all participants.
But what if you're not monotasking (yet)? What if your team is working on multiple topics?
Limit the audience
A good meeting should have an agenda and a laser-sharp audience. Planning meetings are no exception. Each planning meeting should be about a single topic, and only those working on that topic should be in the room. Family members will be very interested in the boring fine print if they're the ones inheriting the land. That also means this planning meeting is ideal for deep discussion: there’s a small set of attendees, and they are invested in the topic.
Make sure to book enough time for these meetings, as this is where a lot of the solution design will happen.
Limit the topics.
One topic is best, but two is better than three. I often see sprint backlogs that are entirely heterogeneous. There's a story about reports, one about archiving, and a bunch of unrelated bugs. If you want to involve the team in planning, then don't spread their attention over a bazillion topics. That's wasteful. If you really have to get through loads of unrelated stories, there's no point in reading them to the crowd. Skip the planning session all together. Just make sure each ticket is well-documented and be available for the inevitable questions.
Instead of organizing all-hands meetings, try scheduling a kick-off call per topic.
Limit the timebox
When a team spends the next three weeks improving the support for automated translations, they don't need to be reminded of the scope. They understand the problem they're solving in that timebox. But when you're in the last week of a three-week potpourri sprint, you probably won't remember what ticket DEF-456 was all about. You've been context-switching so much that you need a reminder. That defeats the point of the planning meeting. If you're planning for multiple topics, limit the length of the timebox. It's better to have three focused one-week sprints than one three-week potpourri sprint.
The point of a planning meeting isn't to tell developers what to work on. It's the start of a new cycle where the team will address new problems. It's the kick-off for a new iteration. We need to engage the team to get the most out of that kick-off. We want them to have room to ask relevant questions and discuss deep insights before they start building a solution.
The best way I've found to do this is to have a planning session for each topic and only invite those who will work on it. That contradicts the general Scrum rules that prefer the entire team to join the meetings. The team-building and knowledge-sharing benefits of a joint kick-off meeting are valuable, but they only emerge when the entire team works on the same problem. If you're not monotasking for one reason or another, kick-offs per topic are much more efficient.