"How long will this take?"
A bead of sweat is rolling down the PMs face. What this stakeholder doesn't know is the team has just started looking at this project. There are wild ass guesstimates and ballparking and all kinds of tricks we can use to come up with a number.
Whatever the answer is it will be wrong. How wrong depends on how good the PM is.
Here is the right answer: 1 sprint (2 weeks).
Treat time as fixed. Always treat it as fixed. Resources are also typically fixed.
That gives you one thing to adjust: scope.
Cut scope to get to a working product/feature in 2 weeks.
I'm not talking about some half built broken thing. Cut scope in the right places so that the main feature(s) can be shipped. Then you can decide wether 2 more weeks would improve things, whether it is ready to ship to users, or whether to drop the idea. Because you've only invested 2 weeks this decision is way easier to make than when months have been spent.
It feels impossible when you first start working in this way. The fears I hear are:
I'll address these in reverse order:
2 weeks is too short
If 2 weeks truly isn't enough time because of the complexity of the work then do longer sprints. Why are you doing 2 week sprints with this crazy complex project in the first place?
Before you switch to 3 month sprints though I challenge you to adjust your expectations on what can be completed in 2 weeks. I believe a product feature can be built, tested, and deployed in 2 weeks. This might mean the back-end is just a JSON file to start out, or, to use a common metaphor, that you deliver a skateboard before trying to build a car.
Stakeholders won't understand
It is the job of the PM (Product, Project, whoever) to make them understand how the process is going to work. Ideally your stakeholders are close enough to the work to see the value of iterative cycles. If not, you need to educate them.
We'll introduce too much tech debt
You will introduce debt. You introduce debt anytime code is merged into master. Stop worrying about tech debt and setup a system to manage the debt. Give 20% of your sprint to payoff debt. Do a 'tech debt' sprint. Don't allow debt to slow you down.
We won't have time for quality
The user doesn't care about quality code. Quality is for the development team and making it easier to onboard new people to the team. Set a standard for code review and quality will be fine. Worst case scenario something gets refactored as part of tech debt cleanup, or the code gets thrown out as the project progresses.
Write code that can be thrown out without too much psychological stress.
Some will find these arguments convincing. The majority of you still don't believe me. The only way to truly prove that this is a better way of working is to try it. Run a sprint with the goal to ship a feature by the end and see what happens. Adapt from there.
One thing I need to re-emphasize: just because you deployed to production doesn't mean you've delivered to users (hopefully you are using feature flags). The decision to open a feature to users should be made by the product owner (main stakeholder). This means a feature could go through 2-3 sprint cycles before it is deemed ready for prime-time. Nobody wants to ship crap, so trust the work that needs more time will get more time.