Week 32 — Capstone build 2¶

At a glance


Date	Friday, May 7, 2027
Unit	4 — Ship It
Big idea	A project becomes stronger when someone else tests it before it is finished.
Goal	Students complete must-have features and run a peer test that produces at least one improvement.
Student accounts needed	None required.
Prep time	5 minutes

Why this lesson looks the way it does¶

Last Friday was about getting the core working. Today is the final real build week before polish and deployment. The temptation is to keep building privately until time runs out. Resist that. Peer testing is the fastest way to make projects understandable to people who did not build them.

The class is mixed-age, which is an advantage here. A 5th grader is an excellent usability tester for a 10th grader's overcomplicated interface. A 10th grader can spot a logic bug in a younger student's game without owning the project.

CSTA 2026 standards¶

Concept area	Connection
Algorithms & Design	Iterate based on peer feedback and prioritize fixes over extra features
Programming	Implement remaining must-have features and debug with test evidence
Data & Analysis	Collect simple feedback: what worked, what confused, what should change
Systems & Security	Confirm saved files and share links are ready for teacher-managed publication
Computing & Society	Make projects understandable and appropriate for an audience beyond the builder

"I can…" objectives¶

By the end of today, students can say:

I can finish the must-have features before adding extras.
I can ask another person to test my project and listen to what confused them.
I can fix one issue based on feedback.
I can explain what remains before final polish.

Teacher prep — the 5-minute version¶

Put these columns on the board: Must-have, Testing, Fixing, Ready for polish.

Prepare a peer test card:

Project tested:
Tester:
What worked?
What confused me?
One suggestion:
One thing I liked:

Reopen platform links.
Have last week's reflection notes ready so you know which projects are behind.

Minute-by-minute run sheet¶

0:00–0:04 — Anchor¶

Say:

"Last Friday the goal was a rough working core. Today the goal is not to add ten features. Today the goal is to make the important part understandable to someone else."

Ask:

"What is your one must-have that still is not done?"

Students answer to their partner, not the whole room.

0:04–0:09 — Mini-lesson: feedback is data¶

Say:

"When a tester gets confused, that is not an insult. It is data. It tells you where the project is not communicating yet."

Model bad vs useful feedback:

Not useful	Useful
"It's bad."	"I didn't know where to click first."
"Make it cooler."	"The enemy moves too fast for a first level."
"I like it."	"The instructions at the top helped me start."

0:09–0:28 — Build block: finish must-haves¶

Students build only must-have features. Your repeated line:

"Nice-if-time features are for after the peer test. What must work before someone else tries it?"

Platform-specific minimums by 0:28:

Website: title, sections, readable styling, no private info
MakeCode: player can start, play, score or progress, and reach win/lose state
Python: program runs from start to finish at least once without crashing

0:28–0:38 — Peer test¶

Pair teams across age when possible. Tester does not get instructions beyond what a normal visitor would see.

Say:

"Builders, hands off the keyboard for the first minute. If you have to explain everything, your project needs clearer instructions."

Testers complete the card. Builders choose exactly one fix to make before class ends.

Ask three teams:

"What did your tester notice that you would not have noticed alone?"

Celebrate fixes, not polish.

0:42–0:45 — Teaser + prompt¶

"Next Friday is polish and deploy. That means titles, instructions, final links, screenshots if needed, and teacher review. Your project does not need to be huge. It needs to be clear, safe, and finished."

Tiered challenges¶

🟢 Starter — grades 5–6¶

Use this tester instruction block on your website or game page:

<section class="instructions">
  <h2>How to use this project</h2>
  <p>Read the steps below, then try it yourself.</p>
  <ol>
    <li>Start here.</li>
    <li>Try the main activity.</li>
    <li>Check your result.</li>
  </ol>
</section>

For Python, add a welcome line and one clear instruction before input().

🟡 Builder — grades 7–8¶

Add one improvement from tester feedback and label it in your notes:

Tester said:
I changed:
Now it works better because:

🔴 Extender — grades 9–10¶

Run an edge-case test:

Website: shrink browser width; is it still readable?
MakeCode: what happens if the player does nothing?
Python: what happens if the user types an unexpected answer?

For Python, handle an unexpected answer:

choice = input("Choose forest or ocean: ").lower()

if choice == "forest":
    print("You found a hidden trail.")
elif choice == "ocean":
    print("You spotted a dolphin.")
else:
    print("That choice is mysterious, so you stay at camp.")

"What is one thing a tester helped you see?"

🤔 Think About This¶

Notice one instruction in the world that is either very clear or very confusing. A sign, a button, a menu, a game tutorial. What made it that way?

🔌 Unplugged Plan B — if the internet is down¶

Turn the day into usability testing on paper.

Time	Activity
0:00–0:04	Anchor: last week core, this week testing
0:04–0:09	Mini-lesson: feedback is data
0:09–0:22	Teams draw the current project screen or write program flow on paper
0:22–0:34	Peer test the paper version: tester points where they would click or predicts what happens next
0:34–0:41	Teams revise instructions, layout, or logic based on tester confusion
0:41–0:45	Share one paper fix and teaser for polish/deploy

This is not wasted time. Many interface problems are easier to see on paper.

Common problems & fixes¶

Problem	Fix
Students resist testing unfinished work	Say, "That is exactly when testing is useful. Finished work is expensive to change."
Tester only says "good"	Require one confusion or one suggestion. If none, tester must name the clearest part and why.
Team adds new feature instead of fixing feedback	Ask whether the new feature helps the showcase visitor understand the project. If not, postpone it.
Python program crashes on unexpected input	Add an `else` branch or simplify choices.
MakeCode game has no win/lose state	Add a score target, countdown, or life count before adding art.
Website still has placeholder text	Replace placeholders before styling anything else.

Vocabulary¶

Peer test — another person trying your project and giving feedback
Feedback — information that helps improve the project
Iteration — making a new version after testing
Usability — how easy a project is for someone else to use
Edge case — an unusual input or situation that might break the project

Reflection — fill in after class¶

Which projects are ready for polish?
Which projects still lack a finish line?
What feedback patterns appeared across the room?
Who needs direct teacher help at the start of Week 33?

Next week: Week 33 — Polish & deploy

Week 32 — Capstone build 2¶

Why this lesson looks the way it does¶

CSTA 2026 standards¶

"I can…" objectives¶

Teacher prep — the 5-minute version¶

Minute-by-minute run sheet¶

0:00–0:04 — Anchor¶

0:04–0:09 — Mini-lesson: feedback is data¶

0:09–0:28 — Build block: finish must-haves¶

0:28–0:38 — Peer test¶

0:38–0:42 — Share-out: one fix from feedback¶

0:42–0:45 — Teaser + prompt¶

Tiered challenges¶

🟢 Starter — grades 5–6¶

🟡 Builder — grades 7–8¶

🔴 Extender — grades 9–10¶

Share-out prompt¶

🤔 Think About This¶

🔌 Unplugged Plan B — if the internet is down¶

Common problems & fixes¶

Vocabulary¶

Reflection — fill in after class¶