The problem with this sort of meeting is that you typically also try and have the stakeholder rank stories at this time. Without a more complete list of stories broken down, the stakeholder isn’t given enough information to be able to decide to go after some "low hanging fruit" stories for a quick win or start tackling some of the epics that will lead to fulfilling more desirable functionality. In software development, I would see this an instance where a combination of concerns is combining to muddy the intent of the meeting. In an effort to increase communication and enabling the stakeholder the ability to have more freedom to decide how they want the application developed, I would suggest that the meeting with the concern to break down a story be separated from that of the planning of an iteration. Leave the story break-down meeting as a separate meeting to facilitate communication between the stakeholder and those implementing the and iteration planning be the domain of the stakeholder.
Iteration planning is a process that has, typically, for me been somewhat problematic. Taking the story backlog, as I mentioned in my previous post, and then having a meeting with the developers to break down a story into a set of tasks and involving the product stakeholders seems to produce a lot of wasted time on everyone’s part. A product stakeholder doesn’t much care to sit there while a group of stories are broken down, but it more concerned with the estimate of the total relative complexity of the tasks required to complete the story. It’s important for them to be there as developers will, hopefully, have questions to ask, testers will be able to add/modify the understanding of the context specifications defined for a story (see my previous post).