Day 28: Practice & Peer Feedback
Wednesday, April 29th, 2026
Warmup
Part 1: Your group provided short descriptions of your game a few days ago. I want to make sure I have a good summary of your game when I setup the Studio to share your projects. Fill out this form to confirm the details.
Part 2: Mr. Willingham will assign your group another group to present and get feedback from. While you wait, open the two rubrics below and read through them — you’ll use both during the work session.
Part 3: Done with all of that? Read the work session while you wait.
Work Session
You have two tasks today. Do them in order — finish your run-through before you swap.
Task 1: Rehearse Your Presentation
Run through your full presentation as a team — out loud, on your feet, as if the class is watching.
Set a timer for 5 minutes
Start the timer the moment your first speaker begins. Stop when you finish your last slide and demo.
Deliver the whole thing
Go slide by slide. Every speaker says their part. Open Scratch and show the demo — don’t skip it.
Check the time
- Under 3 minutes? You need more content or more explanation. Go back and fill in thin slides.
- Over 5 minutes? You need to cut. Trim extra sentences and practice saying things more concisely.
- 3–5 minutes? You’re in the zone. Do one more run-through for confidence.
Fix anything obvious
If a slide is blank, a speaker doesn’t know their part, or the Scratch project doesn’t open — fix it now, before you swap.
Task 2: Present to Another Group
When your team is ready, work with your assigned group and present with them as your audience. Swap and let the other group present to you. Take notes on their presentation and play their Scratch prototype like a real player.
Answer these four questions for the team whose presentation you viewed and whose game you tested:
- What works well? — Name one specific thing that functions correctly and feels good to play. (Example: “The character moves smoothly and the jump feels right.”)
- What’s confusing or broken? — Describe anything that didn’t make sense, got stuck, crashed, or was impossible to figure out without help.
- One suggestion — Give one concrete, actionable idea to improve the game. Be specific. (“Make the enemies faster” is better than “make it harder.”)
- Presentation feedback — What part of the presentation was clear and engaging? What part could be clearer or more interesting?
Feedback should be honest and kind. Don’t say “it’s bad” — say what specifically isn’t working and what could fix it. That’s the kind of feedback that actually helps.
Also, don’t just say “it’s good” — name something that can be improved.
Closing
Tomorrow is your last chance to revise before presentations on Friday. The feedback you received today is only useful if you write it down and look at it again.
Before you close your laptop:
- Make sure your feedback notes are saved — in a doc, on paper, or photographed.
- Decide as a team which piece of feedback is the most important to act on tomorrow.
Standards
- MS-CS-FCP.4.2 — Use the design process to test and revise an idea — today you run your presentation and prototype through a real test cycle and identify what to improve.
- MS-CS-FCP.4.4 — Test a user interface with other users — swapping Scratch prototypes lets real players find bugs and usability problems your team couldn’t see on your own.
- MS-CS-FCP.6.3 — Analyze the functionality and suitability of a computational artifact — giving structured peer feedback requires you to evaluate whether another team’s game does what it’s supposed to do and how well it works for the player.