Estimate nr. of sprints needed to deliver...AGAIN

A Scrum Master ought to be good at wondering. Do the Developers have the skills, authorizations, and other competencies to produce a Done increment at all? They should guarantee to get things Done every Sprint. However small, each increment will be of immediately usable quality.

That's the answer. If it isn't good enough, wonder why. Scrum is about learning to build the right thing at the right time.

There are multiple ways of approaching this.

I'd start with figuring out why the stakeholder needs this information. Understanding what they hope to do with this information may help inform how to work with the stakeholders to better work with agile teams.

In agile ways of working, the team consistently delivers value through the product. Specifically, within the Scrum framework, the team is delivering a valuable Increment at least once per Sprint. Depending on the specific nature of the work, they will be able to see and give feedback on, if not start using, the changes to the product on a regular basis. Through this feedback, they will be changing the work that needs to happen. If they have an initial set of things they believe are necessary, by having the team do the work and then using the product, they may discover that some things on their initial list were unnecessary and can be removed while other things were missed. It may not be possible to know what done is until it's in that state.

Flow gives us another approach. Since agile methods favor empiricism, we learn by doing. One of the things that we learn by doing is how long the doing takes. If we measure the cycle time for work items and the team's throughput, we can forecast when work currently on the backlog will be done. However, we will have to acknowledge the fact that the team may discover previously unknown work or stakeholder feedback may change the Product Backlog before the work is done. Any forecast is based on the understanding at a particular moment in time.

I don't fully understand the problems in creating a Product Backlog. Although it may be true that you have to analyze dependencies and perform refinement and analysis, it seems like identifying the value that stakeholders hope to achieve from the product should be a more straightforward exercise.

DISCLAIMER: I do not work for Daniel S Vacanti or any company with which he is associated.  I recommend these books based upon the success they have helped me achieve. 

I've said this before so I'll be consistent.  Stop using velocity based upon story points for anything.  They just cause confusion.  

"When will it be done" is a common question.  Daniel S. Vacanti wrote 2 books( Actionable Agile Metrics for Predictability and When Will Be Done?) to help you with that problem. You can find them both at this website or for purchase at many other places. I have used both of those books to help educate people on how to forecast work in agile practices.  It is all based upon using flow metrics.  Read the books and I believe it will open up a whole new world for you. 

Using these methods has worked for me when I worked at multiple companies. 

Common pitfalls:

"Stakeholders" want to know how you'll spend the money in the next 6 or at best 3 months and in all that time they will care about one or two things you achieved in the backlog all that time. They won't check your increment every two weeks.

Backlog it's easy in single projects, but in an enterprise architecture, producing an " increment" in a sprint it's almost useless if 4-5 other projects aren't aligned. Backlogs are too fine grained for stakeholders and full of technicalities. That's also means you'll have a meaningful increment in a much longer time.

Thanks for suggesting the book, I've seen already in another thread I'll definitely try to read them.

My personal conclusion is that maybe "scaling' agile in certain environments is tricky at best

"Stakeholders" want to know how you'll spend the money in the next 6 or at best 3 months and in all that time they will care about one or two things you achieved in the backlog all that time. They won't check your increment every two weeks.

If the stakeholders are handing over a stack of requirements and then going away for 3 or more months without collaborating on progress and providing feedback, the team may not benefit from agile methods. Agile methods, like Scrum, are designed to address uncertainty and changing requirements that are inherent in certain types of work. If the people involved in the effort aren't acknowledging that there is value in managing the uncertainty and changing requirements, then an approach that addresses those concerns may not be appropriate.

Funding the effort is orthogonal to collaboration, though. There are reasons why an organization may be more comfortable funding multiple iterations at once, perhaps 3, 4, 6, or 12 months worth of iterations at a time. The Product Owner becomes accountable for maximizing the value delivered in the time that the team has.

It may also be worth considering the iteration length. If two weeks is too short for customer involvement, what about 3 weeks? 4 weeks? Once per month? Scrum requires that Sprints are no longer than 1 month. Other frameworks are longer, but I would be hesitant to go with an iteration length longer than 6 weeks. If you can create accurate plans longer than 6 weeks out, agile methods may add too much overhead.

Backlog it's easy in single projects, but in an enterprise architecture, producing an " increment" in a sprint it's almost useless if 4-5 other projects aren't aligned. Backlogs are too fine grained for stakeholders and full of technicalities. That's also means you'll have a meaningful increment in a much longer time.

If your Product Backlog is too fine grained for stakeholders, it's too fine grained. Your Product Backlog Items should represent things that are valuable for stakeholders. You should be able to complete at least one Product Backlog Item per team per Sprint, so you don't have a long time to wait to get meaningful Increments. You should also be able to identify dependencies for achieving value, which may be different than dependencies for implementing the work, between your Product Backlog Items.

Thanks for suggesting the book, I've seen already in another thread I'll definitely try to read them.

I definitely recommend Vacanti's books. They are quite good. However, it also sounds like you'll need to convince your stakeholders of the value of heeding the advice in the book. That may be a tough challenge.

My personal conclusion is that maybe "scaling' agile in certain environments is tricky at best

Scaling agile is always tricky. You need to consider both horizontal and vertical scaling and then managing dependencies between teams working on a product as well as between products within a portfolio. Your environment will dictate your scaling approaches.

Backlog it's easy in single projects, but in an enterprise architecture, producing an " increment" in a sprint it's almost useless if 4-5 other projects aren't aligned.

I would be amazed if anyone working in today's world could say that they do a lot of work that is not considered Enterprise architecture.  Today that is mostly seen in Academia or very small startup companies trying to identify the basis for their product. But even in Enterprise architecture, producing an increment is quite easy if you have defined your products properly, have a clearly defined product goal, and product backlog items that clearly state the focus. I'll admit it takes discipline at the enterprise level to do, but the results are very much worth the work. 

And I would also question whether you are working at an enterprise level if you are being funded by a stakeholder to build a specific set of requirements in a specific duration of time.  That sounds more like project level work that I am used to because of all the fixed elements. Even if it is being done for large companies, it is still a project based model.  

They won't check your increment every two weeks.

I agree with everything @Thomas said on this.  If the stakeholders do not want to be involved, why is your organization using Scrum?  What is the benefit that they hope to gain?  Could it be that you have internal stakeholders that could be utilized instead of the external stakeholders? No where in the Scrum Guide does it define the stakeholders. Could it be that you are not properly identifying your stakeholders?  Could another of your teams be the stakeholders for your part of the work? The Scrum Glossary here at scrum.org provides this definition

Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.