You want to keep related changes together. For example, if you implement bidirectional relation and add columns/tables to suffice AR relations you want to keep those in one migration.
If changes in schema are not related to each other (parts of different features, for example) it's better to keep them in separate migrations.
I do a mental experiment when I'm not sure. I try to break up migration for the smallest possible pieces and then check if my feature still works if I take down only one of the pieces. If it is that piece is likely doesn't belong to this migration.
Yours look to me like it can be split into two migrations. It seem to be you have two features here. One is about adding schedules for players and another for adding coaches to schedules.