Planning end date

If the size of a Product Backlog is known, and a team can evidence progress by means of work Done every Sprint, then an end-date of sorts may be projected.

However, might it be best to plan as though the last day of each Sprint were a potential end-date?

Jason,

Since change will always happen, it is no wonder that your manager's meticulous plans went off track very early.   Agile/Scrum evolved in part due to a desire to embrace "change" instead of fighting it through command and control tactics.

The 2nd Agile principle: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage".

Agile/Scrum is about starting as soon as possible with what you can deliver (as small as it may be) in order to learn, solicit feedback, and evolve the "plan" to continue creating and delivering incrementally.

In regards to your "end date" question, it is easiest to look at the triple constraints of a traditional project (time, cost, scope), and how that changes under Scrum.   In a traditional project, those three items (along with quality) can be adjusted as needed in order to keep to an artificial deadline (ex: extend target date, add more people, decrease delivered functionality, allow tech debt, reduce testing time, etc.)

With Scrum, three of the constraints are fixed (time - sprint length, cost - stable team, quality - meets Definition of Done).   The only constraint that is variable is Scope.   You can therefore establish an "end date" for your initiative, and when that date arrives, it arrives.   Ideally, you will have all of the functionality desired (including additional features identified through empiricism sprint to sprint), but if for whatever reason you did not meet all of the "scope" originally envisioned, you should have at least the most critical (important) features completed.   And perhaps, some of the functionality thought of in the beginning will be deemed unnecessary by the end date.

Hope this helps.   Good luck!