Agile doesn't mean "don't plan", so there should be plenty to talk about.
Have your students developed user stories? Can they talk about these? For example, let's take this example user story:
As a teacher, I want to automatically mark assignments so I'm not spending time checking code that could be done automatically.
It might be worthwhile to encourage your students to consider how and why they wrote their user stories as they did. You can check that they're not developing user stories that are too broad (too many epics rather than stories) as they go along if you want to provide some support and prevent them from being too unrealistic.
As you should probably be estimating the amount of work for each user story, ask them to document that so you can check it. Unrealistic timings—or no timings at all—should be caught early so that you can make sure they finish the project on time.
If you follow the 'planning game' of XP, then you can also look at how the requirements were sorted by risk and value. Yet another point to document and mark if needed.
As mentioned by Kaneki, sprint retrospectives provide time for your students to reflect on their progress. Encourage them to use this wisely in place of a huge specification detailing implementations, tests, etc.
In short, there's loads to document about Agile, but you might not need to write everything on paper. If it's easier for you, consider just being a part of the retrospective meetings and looking at how these go instead of meticulously writing down every detail.