Have led one engineering team and worked with a much larger geographically distributed team, the answer depends on your specific situation.

Many advocates of Agile insist that it can only be done properly if engineers and your internal product experts are the same location, or at least in the same time zone. You mentioned "Scrum" but didn't say this was case.

Unfortunately, "Agile" and "Scrum" are these sexy buzzwords that entrepreneurs and managers like to promise to investors even when they cannot possible practice Scrum because their engineers and internal project managers are on separate continents. They practice some sort of non-Agile methodology, although to keep the investors under the illusion of Agile they'll hold "Scrum" meeting and use Agile buzzwords. They will doing something very specification heavy, or with much slower iterative cycles, but they'll still run around insisting they are doing Agile.

Google and other large corporations apparently have mathematical predictive models for figuring out the number of engineers required on any one project. "Lean methodologies" like six sigma may also try to build these from your existing client data. There is a group at Carnegie Melon that studies (and consults on this) and has found that geographic distribution plays a major role in the optimal type of methodology (Agile versus non-Agile) you should be using on your given project.

So I would need to know a lot more about your project management and engineering organization to answer this question. Are you a small start-up or a large organization? How existing data, if any, do you have on completed projects? Will your software engineers be nearby or on a different continent.

If need help figuring out the ideal methodology for your project, the CMU group I mentioned has published a number of books available off Amazon that can help you make the optimal selection. If you are a new organization starting from scratch but really are doing Agile/scrum (and not just running around saying this to impress investors) there are, of course, very good books and YouTube videos on scrum methodology.

If you're an existing mid-size to large organization, your PMs or in-house six sigma experts might be the best people to ask. Regardless of whether or not you already have a six-sigma (or equivalent) style organization in house, getting access to the past project data that these sorts of experts look at can be extremely valuable. You can figure out the pain-points in each project, and the amount of engineering and time resources that each pain point typically requires to address.

I'd be more than happy to further share my expertise on a Clarity call.