In your experience, how long should a Sprint Planning meeting (Scrum) last? 8 hours? Or should it be shorter (succinct) and further discussions should be planned as part of the sprint? Our Sprints are 10 days long.
According to the Scrum Guide:
The Sprint Planning Meeting is time-boxed to eight hours for a one-month Sprint. For shorter Sprints, the event is proportionately shorter. For example, two-week Sprints have four-hour Sprint Planning Meetings.
That generally works for me.
As long as it needs to last, no less and no more. Anything else isn't Agile.
If you have a team of 2 - 3 developers and are doing 1 week sprints anything more than a hour is probably counter productive.
If you have a team of 15 people and 2 weeks sprints you are looking at all day, anything less isn't detailed enough.
It takes experience to get it mostly right, and that is what retrospectives are for, the team decides what is too long or too short.
Don't worry about getting it perfect or sticking to what some book says, try something and refine it.
SCRUM is about refining the process in iterations as much as it is about refining your code in iterations.
Do not mold your business around the process. The process supports your business. The moment you're doing process for its own sake it's time for the process to get the axe. To that end, there is no "right" way. Meetings should only go as long as you are accomplishing something in them. If it takes you 30 minutes or 4 hours, as long as it works then go with it. Ignore what some book/blog/coach tells you and do what is right for you.
Take as long as you need so that you select enough that your team thinks they can reasonably achieve in the sprint. But you should be spending time during the (previous) sprint refining the backlog: estimating and refining stories.
From the Scrum Primer (PDF):
Product Backlog Refinement
One of the lesser known, but valuable, guidelines in Scrum is that five or ten percent of each Sprint must be dedicated by the Team to refining (or “grooming”) the Product Backlog. This includes detailed requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. Scrum is silent on how this work is done, but a frequently used technique is a focused workshop near the end of the Sprint, so that the Team and Product Owner can dedicate themselves to this work without interruption. For a two-week Sprint, five percent of the duration implies that each Sprint there is a half-day Product Backlog Refinement workshop. This refinement activity is not for items selected for the current Sprint; it is for items for the future, most likely in the next one or two Sprints. With this practice, Sprint Planning becomes relatively simple because the Product Owner and Scrum Team start the planning with a clear, well-analyzed and carefully estimated set of items. A sign that this refinement workshop is not being done (or not being done well) is that Sprint Planning involves significant questions, discovery, or confusion and feels incomplete; planning work then often spills over into the Sprint itself, which is typically not desirable.
Doing this means you can focus on planning during planning, and it doesn't take all day and the team starts to lose focus and get bored.
In Scrum, when working to 2 week sprints, the sprint planning is time-boxed at 4 hours, making it a half day event. One reason for the relatively large amount of time is that the development team must be able to confidently agree that all items being pulled into the sprint backlog can be delivered, which means they need to know the detail. It is not uncommon as part of sprint planning for teams to break off from the meeting space for periods of time in order to investigate items further and ensure that they are "Ready" to go into the sprint backlog. (It can help to think of sprint planning as an event, rather than a meeting.)
Use your "Definition of Ready" and the length of time that the sprint planning event allows to ensure that all backlog items going into the sprint are both feasible and ready. i.e. They can be done (completely, as per "Definition of Done") within the sprint, and there is enough information for the team to be able to do them right now.
Note of course that you probably don't want to be doing this for ALL items during the sprint planning, as it can be very time consuming. Do try and have regular backlog grooming (outwith sprint planning) where you can breakdown backlog items, and estimate items not yet estimated using planning poker for example. (I've found this can be a effective activity for over a working dinner with the development team, should you have the luxury of your team's availability at dinner time!)
High priority items can often be added to the product backlog by the product owner just prior to sprint planning though, and whilst routine backlog grooming can, and normally should, be done before the sprint planning event, there will always be new items like this where the team needs to spend time working out the detail and estimating complexity during the sprint planning event, hence why it can stretch to 4 hours for 10 day/2 week sprints.
If you need to take longer discussions out of this event, then you might have a backlog item in the sprint backlog to "have such and such a discussion to establish x", but you should avoid including sprint items to do whatever you are going to determine needs done during that discussion, as those are not "ready" backlog items to go into the sprint.
As people have said, there are reasons you might want to change the way you run Scrum if the process isn't working effectively for you. Scrum is however, a very well thought out and tested framework to start with so I would make sure your reasoning is justified before changing the process.
In the Sprint Planning Meeting, the team has to determine two sets of things:
A) What will be developed by the team during this Sprint
B) How it will be developed
This meeting must be time-boxed, up to two hours for each week of the Sprint, split evenly for each part (part A and Part B) of the meeting.
So, for a Sprint of 4 weeks, this meeting should be no longer than 8 hours, up to 4 hours for part A and up to 4 hours for part B.
During part A, the dev team has to estimate the team velocity that they consider they will have during this Sprint. They also have to estimate the top priority user stories, and choose enough of these (already estimated) user stories to complete in line with their own estimated team velocity.
In part B, the dev team will discuss how to develop the more challenging user stories already selected to be developed. Most probably, the dev team will not have enough time to discuss how to develop all the selected user stories, so, the team has to choose the most challenging user stories.
During the Sprint, the dev team has enough time to complete this discussion.
According to the Scrum Guide:
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.