Let me ask a couple of questions. First, how do you know you have a 100 person-month (staff-month) project? (I know, by estimating, of course.) What did you base your estimate on? A project plan with a detailed WBS? A detailed UML model? A Scrum product backlog filled with user stories? Or, a project vision statement? A guess?
The reason these questions are pertinent is that they drive home the importance of planning. Whether you're using deterministic or Agile project management techniques, you still have to plan and you have to base your plan on some understanding of exactly what it is you're trying to do, and how. Release planning is critical regardless of your project management methodology, and resource scheduling is a component of release planning.
If we assume that 100 staff-months are accurate, then if resources are truly unconstrained, why not put 100 people on it for a month and get it out in 30 days or less? We could do this if the work was broken down into 100 one-month tasks that could be implemented independently... but very few substantial projects can be decomposed down to 1% increments of work that have no dependencies. Therefore, the next step is to indentify the technical dependencies that force us to group work into 'chains' where tasks must be done sequentially, which means the next step is really decomposition (breaking up larger work items into the smaller work items that must be done to implement them) and disaggregation (breaking up collections of related but implementation-independent items into their constituent parts). Once you reduce the mountains into boulders or even rocks then you can start to see how it all fits together and what needs to be done in what order. In short, you can start to understand the technical dependencies that force the sequence that work items are implemented. Breaking work down also improves the accuracy of your estimates.
There’s more to this than technical dependencies, however. We initiate projects to solve business problems, and so there are also business dependencies that may affect the sequence of implementation. Therefore, we should implement a project in the order that provides the maximum business value as quickly as possible while reflecting technical dependencies. Our goal, whether we’re using a traditional deterministic project management methodology or an Agile methodology, is to create a sequence of work item implementation that becomes our release plan reflected either as a project schedule (deterministic) or a prioritized product backlog (Agile). A network activity chart, or PERT chart, is one way of displaying technical dependencies, and is useful even for Agile planning when done at a high level. PERT charts graphically display dependencies as well as opportunities for simultaneous implementation. Some Agile groups will use a large wall in a conference room or team hallway and re-arrange Post-It notes to create the release plan, grouping backlog items by iteration, and even creating parallel team backlogs from the overall product backlog, the result being akin to a PERT chart. Now we understand the overall order of implementation, and what can be done in parallel, and when, so we can derive a resource schedule, whether it’s resource assignments on a Gantt chart or establishing Scrum teams with their own team-specific release backlogs.
So, as you can see, there's more to resource scheduling than having an estimate of the project's required effort. The approach described above should help you determine the answer that is right for your organization and project.