Regarding your questions:
1) I organize all of the tasks necessary to build the particular piece into the module. This means business requirements, use cases, code, QA time, everything. I leave my dependencies in place- for example, the release of the functionality in the “module” to production has a dependency on the completion of the release that the module is going to be included in. It creates a little overhead for me to do this, but as you said, it helps the agile team communicate where they are.

2) I add the next level of detail below it. For reasons why, see above- it lets me hook in the appropriate predecessors when needed. For example, in our environment, development items go to QA, UAT or production in bundles of these “modules”. By having a task for QA, UAT and production release, I can drop in the predecessors hooked to a master “deploy to ” task for that release.

3) This is where art meets science for this. If your team is dedicated resources, you can simply level by modules. Otherwise you have to level by WBS.

1) What are you organizing into modules? Is it use-cases or other immediately-value-enabling collections-of-stuff? Or is it the work breakdown structure for a sprint (define d in some other way)?

2) When you add the module to your project plan, are you adding the next level of detail below it? In my experience, the utility (or maybe the ROI) of this is inversely proportional to the complexity of the project.

3) How do you address leveling, when either a)you only track modules, which are multi-person, or b)you track the WBS, which an agile team will self-manage into different individual assignments within the sprint.

Thanks again!