How long does it take to plan the next sprint? I'm talking about the particular sprint planning meeting where all members of a team agree what they should be doing in the next two weeks.
You may know it as "The Planning". I told you the grooming is your primary weapon of choice. That said, the planning is the secondary one. Double the gun, double the fun.
Back to the question. How much time does your planning consume? One hour? Thirty minutes, maybe? Believe or not, fifteen minutes should be more than enough. The right question is why should you need more time than a lousy quarter of an hour?
Backlog
Every team member has to be aware of the top issues in the backlog. For a simple reason. If you're sitting in the meeting room choosing what to do in the next sprint and what can wait, you have to know the priorities—then you can go from the top and choose the right stuff. The worst thing that can happen is to start asking questions like "Why do we want that?" or "What the hell does it even mean?". It could happen that you run into an older story, and this type of discussion will hit you in the face. Stay calm and skip it if possible. You will have time to explain the unknown during another grooming.
Groomed Stories
That leads us to a well-known fact. The stories at the top of the backlog must be well groomed. This doesn't mean you can see a number next to the story title but that you know what the goal is and what has to be done to accomplish this aim. Therefore, you can make a plan for the next two weeks and evaluate if this plan is just right, concerning the overall intent and upcoming holidays or vacations. This is something that cannot be done precisely with a mathematic formula—way too many variables. You will gain a lot more with clear judgment than with an exact sum that equals your velocity.
Preparation
Planning is not only about the backlog items but also about bugs, defects, and team availability. However, the meeting itself is not the place to make a head count. Also, it's not the place to go through unknown defects and read through definitions. You have to prepare this before the meeting. Always make sure you know the state of your entire team before planning. Do you have a ton of customer bugs? Ask your teammates how this will impact on your work and plan accordingly. But do this before the actual planning. Don't let other teams or your cherished product owner wait for you because you have underestimated the preparation.
Sir! Yes, Sir!
For me, the planning is always a consensus. It's not just some word of command. Everyone should be obligated to express a disagreement if the priority is incorrect, or the plan won't lead us to a successful finish. We don't implement things because they are in the backlog. We are building the best product ever. That's your master plan.
Planning must be a blitzkrieg. A meetup that is a few minutes long where you make a line in the backlog, choose the right set of stories, make sure everyone agrees and shakes hands. It's not rocket science. There's a minimum length limit for a blog post. I'm violating this rule with this one to make a point. Don't make things longer than they are supposed to be. Use the spare time for important things.