One thing to note is that the domain of agility withing Agile Methodology is not simply the domain of the developer. It is certainly within the realm of possibility that, as the discussion ensues, the story breaks out a number of other stories becomes an epic and is further broken down into a series of other stories. This is where, I believe, the art and beauty of the Agile comes into play. That we are all imperfect but all working toward a common goal of making something to improve acknowledges the humanity of all involved in the process and truly does improve each person involved.
In a previous post I had mentioned the use of Fibonacci numbers to estimate the tasks. During a discussion between developers, testers and the stakeholder, stories are broken down into a series of understood development tasks. Each of the tasks is then estimated based on relative complexity. At this point I imagine being asked "How far should you break down a story?" to which I would reply that it depends solely on the comfort level of the developers to know what’s involved in completing the story. I would suspect that early on in a project, when there is a lot of unknown technical details on how a story is to be implemented, a lot of small tasks would be created. As the number of unknown technical details decreases, I would suspect it would lead to teams to generalize tasks a little more. The end result is the same. The tasks involved in completing a story are defined and estimated. The take-away from this discussion is to give the stakeholder the ability to know more about the difficulty of implementing a story and giving them the ability to make more educated decisions when deciding what stories they would like to have in the upcoming iteration.