You can have a deadline but no fixed scope, this what CI/CD is for. So when deadline day happens what you have is already released.
Or you can have fixed scope but no deadline.
Or you can have fixed scope & deadline, then pad things to hedge risks that might pop out.
Agile prefers the first.
And almost never does because it's designed in a way that's easy to abuse. Instead you often see dynamic ever-changing scope, dynamic ever tightening deadlines, and no margins for risk. Everything is on fire always and you just chase the fires around with your dev teams to put out fires, crack whips, and ask why features are behind schedule. It's madness in much of the industry.
Maybe, but I am not sure, and that’s not the way I’ve ever seen it done.
The only way I’ve ever seen agile done is “waterfall with two week sprints”. Large wireframes of an entire application which is “unreleasable” until the end.
Sure it compiles during each sprint, but it’s not a releasable product at any stage (until the mad rush at the end when all the negotiations and trade offs begin)
You can set out to have a set of features, and you can have a deadline, but thinking all the features will be completed (and completed well), on that day has never worked (in my experience). You just wind up with rush hacked garbage towards the end.
This is what I’ve done successfully for years now (when I am not forced by a PM to do agile): https://concentric.works/