Agile & MS Project :

I would consider myself an MS Project "expert" and while I am a certified Professional Scrum Master (PSM), I am very beginner when it comes to agile, with limited professional experience.

I would be interested to gain more experience with agile. I foresee using MS Project in an agile environment in a manner such as this, but would be curious to hear how others have been using it, or why they feel it's unnecessary to use a scheduling tool. I know there are existing PMI webinars on scheduling in an agile environment you can lookup as well:
-Create a "parking lot" of the Product Backlog Items near bottom of the schedule.
-Create sprints as "planning packages" with their timebox durations and link them to milestones such as release dates. This way you can see sprint durations and quantities leading to major milestones. Dependencies may exist at the sprint level.
-Per scrum, pull PBIs up into the sprint as it becomes time. Perhaps they can be notionally assigned to the next few sprints if desired, to see/predict functionality to be phased in over time. As other's have said, this will be very fluid. At the end/start of each sprint items will be pushed/pulled out of and into the current sprint which will affect subsequent sprints. This is fairly quick and easy to make these adjustments in project within the summary tasks and modifications of dependencies.
-If you have multiple scrum teams (scrum of scrums) you can have multiple sprints running in parallel driving functionality milestones/releases/deliverables.
-Other external (schedule visibility) tasks case be added as needed that affect development such as: hiring of specific skillsets, adding of infrastructure, third party dependencies, signing of contracts, etc. In the three dimensional world these dependencies do exist and having them in the schedule will help ensure they are managed accordingly.

As I said - I am an agile/Scrum beginner but these are my thoughts. I really do like MS Project and integrated schedules as an organization tool, if nothing else or more than that.

I would consider myself an MS Project "expert" and while I am a certified Professional Scrum Master (PSM), I am very beginner when it comes to agile, with limited professional experience.

I would be interested to gain more experience with agile. I foresee using MS Project in an agile environment in a manner such as this, but would be curious to hear how others have been using it, or why they feel it's unnecessary to use a scheduling tool. I know there are existing PMI webinars on scheduling in an agile environment you can lookup as well:
-Create a "parking lot" of the Product Backlog Items near bottom of the schedule.
-Create sprints as "planning packages" with their timebox durations and link them to milestones such as release dates. This way you can see sprint durations and quantities leading to major milestones. Dependencies may exist at the sprint level.
-Per scrum, pull PBIs up into the sprint as it becomes time. Perhaps they can be notionally assigned to the next few sprints if desired, to see/predict functionality to be phased in over time. As other's have said, this will be very fluid. At the end/start of each sprint items will be pushed/pulled out of and into the current sprint which will affect subsequent sprints. This is fairly quick and easy to make these adjustments in project within the summary tasks and modifications of dependencies.
-If you have multiple scrum teams (scrum of scrums) you can have multiple sprints running in parallel driving functionality milestones/releases/deliverables.
-Other external (schedule visibility) tasks case be added as needed that affect development such as: hiring of specific skillsets, adding of infrastructure, third party dependencies, signing of contracts, etc. In the three dimensional world these dependencies do exist and having them in the schedule will help ensure they are managed accordingly.

As I said - I am an agile/Scrum beginner but these are my thoughts. I really do like MS Project and integrated schedules as an organization tool, if nothing else or more than that.