This is mainly a question for experienced Agile teams who are comprised of both business analysts and dev/qa teams like we are.

We're on sprint 3 of this new process and although it's going well overall, the sprint planning sessions are painful and LONG. We have professional Agile coaches helping us out but we're still struggling with this bit. They are advising us to have everyone estimating each story/task using "planning poker" (we're using fibonacci numbers). The problem is that the analysts don't know how to estimate development or testing, and the developers and QA people don't know how to estimate documentation work. So for each and every story we have to spend 10 - 20 minutes explaining what the story/task entails so that everyone can give at least a semi-educated estimate. Which then means that in an hour planning session, we only get about 4 - 5 stories/tasks estimated and assigned to the sprint, and then have to schedule another freaking planning meeting to finish up.

Is this normal for teams that are just starting out, and we should schedule 2-3 hour planning sessions for a while? Is there a way to make this easier and less drawn out and painful? Is it because of some other reason, like too large of a workload for the headcount? (We have about 3 developers, 2 QA people, 3 analysts, a product owner and a scrum master.) I'm one of the analysts and I've been analyzing this process and I can't figure out what the problem is or possible solutions.