The original project managment triangle which has been used now since around 60 to 70 years
defined a scope, costs and a deadline. As a result the quality suffered in so many projects as one or more corners exeeded the limit.
Even Agile is around since 20 years, projects are still planned within this triangle. A scope is defined, costs are predicted and when working time is estimated and based on this a release date announced, the chance of low quality is high. Or costs or/and time exploded to reach the targeted quality level.
What is here the Agile way to prevent poor solutions? Flip the triangle! Instead of have a fix scope, you know the sprint length and the costs of the team members. The scope is estimated but not set in stone. As quality is not negotiable on the release day not everything might be finished but it is releaseable.
Now - if you are thinking now that your recent projects would have failed with a smaller scope or would not be releaseable with a smaller scope, then probably one of the both fixed elements - costs or time have been wrong. Sure not everything can be released even if the quality is ok. If you e.g. implement an shopping basket only for the half, it might not be releaseable so you need to postpone it. In this case the time corner was set wrong.
In practice the costs in agile developement projects are normally fixed as the development team does not change so often. As quality should also be a hard requirement there is not much space to negotiate. So scope and time can vary in a project.
