In the early iterations of Team Skill 3, Defining the System, most of the major use cases are identified, but only a few ”perhaps those considered architecturally significant or particularly descriptive of the system behavior ”are well described. The refining stages complete the process by describing all the use cases needed to define the system. The test for "enough" use cases is that the complete collection of use cases describes all possible ways in which the system can be used, at a level of specificity suitable to drive design, implementation, and testing.
It's worth noting that use-case elaboration is not system decomposition. That is, we don't start with a high-level use case and decompose it into more and more use cases. Instead, we are searching for more and more detailed interactions of the actors with the system. Thus, use-case elaboration is more closely aligned with refining a series of actions rather than hierarchically dividing actions into subactions. However, your model may have use cases that are so simple that they do not need a detailed description of the flow of events; a simple outline is quite enough. The criteria for making this elaboration decision are that users don't disagree on what the use case means and that designers and testers are comfortable with the level of detail provided by the simple format. If all is well, you can then proceed straight to design and coding.