I think you have fundamentally misunderstood the relationship between plans, stages and jobs in bamboo.
A good rule of thumb is to have a single repository of code, which is linked to a single build plan, which produces a single independent module.
You may initially start out creating a single stage with a single job inside each single plan where you just run a single maven command and the unit tests built into your maven build may be perfectly sufficient to exercise your modules completely in this extremely simple use case you probably don't need a tool like bamboo or Jenkins to deal with your builds.
However, very quickly your conceptualisation of a "build" gets very complicated. As you mentioned in your question you might quickly amass multiple modules that are interrelated, or you might need to support your code on multiple platforms or in multiple browsers, and if you get all the way to the CD end of the work flow you might even need to deploy binaries into environments as the result of a code change.
This is where you would want to use the extra orchestration capabilities of your CI tool.
For example, if you are developing a module that you expect to load in a browser then your might have a build pipeline that looks like:
Check in Code -> Build/Compile/Unit Test -> Deploy to a CI environment -> Stand up a half dozen browsers and verify that they all still work correctly.
In the above work flow you would have a single stage to handle your compilation and unit testing which would spit out a compiled or built artifact. Then you have a stage that does whatever needs doing to make your module useful, ie it might create your final shippable product by combining your module with other modules built from other plans, or it might package some software into an RPM, a DEB and so on, depends what you're actually building. If you need to ship to multiple platforms then this is your first stage where parallelism becomes meaningful.
Alternatively, if you are building for a single platform but for multiple consumers you might follow up this build of your component with a bunch of headless browsers kicking off test cases to validate that your changes didn't break anything. These can all happen in parallel on different agents running in different OS's, depends how you have bamboo configured.
Then finally, assuming you are shopping something more complex than a single module, you will want to do a bit of integration testing with all the other components that you need to interact with. This step will usually be separated into a build plan of its own, triggered by the successful completion of the plans which are spitting out individual modules. Here you get a chance to run all the same tests but with your latest version running along side everyone else's module so you can be sure that there are no breakages caused by dependencies.
So at any one time you only have a single repo triggering a single plan. If you have multiple repositories feeding into the same plan and they are completely unrelated but use the same build pipeline then I'd recommend taking advantage of bamboos plan branches so that you can reuse the same build process but with multiple different code bases (if that fits your use case)
