SPIKE™ Prime with Python

Ideas to Help with Game Time

Practice giving and using feedback from others.

45 min
Intermed.
Years 7-9 OR Key Stage 3

Questions to investigate

• How can input from others help me make a better design and program?

Prepare

• Ensure SPIKE Prime hubs are charged, especially if connecting through Bluetooth.
• Ensure students have their built model from the game time lesson.

Engage

(Group Discussion, 5 minutes)

Review the model for providing feedback with students.

Explain to students the following guidelines for giving feedback. Consider posting the guidelines for student reference.
• Feedback is not doing something for someone else.
• You should not rebuild a model for someone else.
• You should not type into someone’s program.
• You should ask questions of each other.
• You should share your ideas and show your own programming, explaining why and how you did something.
• You should be encouraging and helpful to others and not provide negative or mean comments.

Explore

(Small Groups, 20 minutes)

Have students work together to provide feedback to each other about the Game Time models.

Have two teams work together to provide feedback to each other. Teachers should model the process and what specific feedback looks and sounds like.

Review the procedure with students. Then have students take turns providing feedback.
• Team B will show their working model.
• Team A provides feedback while Team B takes notes in their journal.
• Then teams can switch roles. Team A will show their working model and take notes while Team B provides feedback.

Feedback should include:
1. Tell something they really like. This could be the model, program, or design.
2. Tell something that worked well.
3. Share something the group could try differently.
4. Share anything that is confusing, did not work or that could be improved,
• Remind students to be kind and clear in explaining why it is not clear or could be improved.
• Let the team receiving the feedback ask questions as needed for more clarity.
• The team giving feedback can also share ideas for improvement.

Teacher tip – Model providing feedback for the class frequently to help them learn to use positive language instead of negative language when providing feedback. Also practice taking feedback and thinking about how to use it rather than becoming defensive.

Explain

(Whole Group, 5 minutes)

Have students discuss what they learned from their feedback session.
Ask students questions like:
• What did you notice in models that worked well?
• What ideas did you get from others?
• What is something you can do with your feedback?

Elaborate

(Small Groups, 10 minutes)

Students should incorporate the feedback they were given.

Give students time to modify their designs and program based on the feedback they received. Have students document their changes in their journal.

Allow students to share their updated models and programs. Ask students to share what changes they incorporated and how they were able to make the changes.

Evaluate

(Group Exercise, 5 minutes)

Teacher Observation:
Discuss the program with students.
Ask students questions like:
• How did you use the feedback given?
• How did it feel to give feedback to others? And to receive it?
• How did you work to provide good feedback today?

Self-Assessment:
Have students answer the following in their journals:
• What did you learn today about providing good feedback?
• What did you learn today about how feedback can help in your work?
• What characteristics of a good teammate did I display today?
• Ask students to rate themselves on a scale of 1-3, on their time management today.
• Ask students to rate themselves on a scale of 1-3, on their materials (parts) management today.

Teacher Support

Students will:
• Give specific feedback on a peer’s project.
• Explore how to use feedback to improve a project.

• SPIKE Prime sets ready for student use
• Devices with the SPIKE App installed
• Student journals
• Models from the Game Time lesson

CSTA
1B-IC-20 Seek diverse perspectives for the purpose of improving computational artifacts.