The biggest issue I see is that you are taking your curriculum and trying to approach it using SCRUM terms. The result is a lot of "almost SCRUM" behaviors which could be tremendously damaging. I've seen many SCRUM teams fail because a Product Owner or Scrum Master forced "almost SCRUM" mentalities on the team.
Instead of taking your curriculum and trying to approach it with SCRUM terms, I recommend starting with the SCRUM process, and trying to apply it to your curriculum. The reason I think this will work better is because SCRUM is designed to produce a product, such as the learning of your curriculum. Your curriculum is not necessarily designed to operate in SCRUM. Let SCRUM take charge, and do what it's good at.
One key aspect of this application is that you are going to wear three hats: Product Owner, Scrum Master, and Manager. Manager is not actually a SCRUM role, but it is essential for stability. If a real life SCRUM team refuses to build sprints which support the Product Owner sufficiently, That PO will have a talk with the functional management of the team and everyone will be receiving bad performance reviews for the year. The school-house equivalent for that is being given a bad grade. Thus, "support of the SCRUM process" should be a line item in your grades for the students. Maybe you tell the students that the first 10-20% of their grade is "free" unless they disrupt the SCRUM process enough to force you (as the PO) to have a talk with yourself (as the manager). If you coach it right, they'll think of it as a free A on a test or something like that.
With that ugly manager hat out of the way, we can look at the other ones. Product Owner will be the most interesting. Like an industry PO, you have an obligation to produce a product for your customer: your administration and these children's parents expect learning. Explain to the students that, when you're wearing the PO hat, your job is to deliver the curriculum to the expectations of these customers.
I would expect two major styles of behavior here. If the students are on-pace with the curriculum, the PO should operate like any real-life product owner would: egging the team on to produce more product faster, and maybe giving them more freedom to craft the backlog the way they want to see it. However, if the students are falling behind (i.e. the PO may not be able to deliver the "learning" to the customer), and the students aren't ameliorating this in their sprints, the PO should start tightening the reins offering less agility, and instead picking sure-fire ways to cover the material (which are probably more boring), and you will be talking with yourself (as Manager) about those SCRUM grades. The students should understand this up front. If they start to fall behind, there should be a desire on their part to resolve the issue before the PO comes in and takes away their freedoms. It should be easy enough for them to understand, but knowing how the game works up-front is key.
Then there's the Scrum Master. The SM is known as the "servant-leader" of the team. They are there to facilitate the team in any way needed to make the SCRUM team successful. Note how different that job description is from the PO. You are going to need to make it very clear when you are acting as SM and when you are acting as PO. This might actually involve funny headgear, or it might just involve some metacommunicating to tell people who you are acting as.
As an example, let's recognize that this SCRUM effort is an experiment. It might not actually fit well into the school model. What happens if it's a bad match? The first thing that you'll notice is that you (as PO), start to get unhappy because you're not delivering "learning" on-time. You're falling behind schedule. The PO is then going to push on the team to produce more. As SM, you then need to work with them to try to plan better sprints to meet the PO's needs. Now in this case, we're looking at the case where this fails. Now the PO is extremely unhappy and is ready to talk to the Manager about how bad the team is performing (and take away their SCRUM support grade). At this point, you might need to do some metacommunication to recover:
So I wanted to try to run this class in a SCRUM setting. As you've seen from my emails to you guys as Product Owner, I'm not happy with the results. Your SCRUM effort is simply not working.
At this point, a real Product Owner and a real Scrum Master would sit down and talk about what's going on. They'd try to identify the root cause. So as Scrum Master, the servant-leader of the group, I'd come to the table arguing that the team is actually doing their job, the task was just too big.
At this point in the semester, I, as Product Owner, agree with the Scrum Master. You guys have done your job making SCRUM work as best as it could. The curriculum just doesn't fit. So as Product Owner, I'm deciding to terminate the SCRUM and go back to a traditional teaching approach. Since its clear you guys did your job for making it work, I'm not going to the Manager to try to ding you guys for your performance. You did great. You all get the 20% SCRUM support points. But instead of it being part of scrum, it's just going to be like it was a Test. It's like a test you didn't have to study for, and you all got A's. Congratulations.
Now back to your regularly scheduled classroom.
Can you see how murky that would be if you blurred the 3 hats? It needs to be clear that, in this process, you will have at least 1 person in your corner: your Scrum Master. If they can't see that, they may rebel against the idea.
Now sprint planning will be the last major challenge I think. There's a few issues here. One is that you have too many people on the team. SCRUM teams work best in small numbers. A classroom is likely too many. You will probably have to adapt the sprint planning process to fit reality.
The other challenge in planning is that your students aren't the experts here. You are. They don't really know enough to break down the backlog items into tasks that can fit into the sprint. As a result, you may have to help. As part of the Product Backlog, you may want to provide suggestions for how to approach each curriculum item (such as "Lecture" and "Problem set A" and "Problem set B" and "Research"), along with some way of estimating how long the task should take. Let them assign the story points -- it's an essential learning process for SCRUM. If they want to try to learn the curriculum in a different way from what you provided, then you may need to introduce the concept of the Sprint Goal, and explain how they can use that to provide cohesion.
Also, do remember flexibility. As a PO, you are going to have to demonstrate to your customers that these students learned the material. That's all. If you can work with them to find clever ways to demonstrate that they are learning what they need to learn, then always let them deviate from the obvious curriculum. If you're teaching sockets, do you really need the backlog item "Learn to use select()?" Or can we add a new item "use asynchronous threads to add functionality to the awesome product produced last sprint?" The answer really depends on how much freedom you have in your curriculum.
