Innovation Lab Showcase

Overview

This flexible Innovation Lab session lets students finalize incomplete Micro:bit projects, extend a chosen project, or peer-troubleshoot with teacher mini-conferences. Students also prepare a brief 60-second pitch and end with a voluntary peer showcase.

Learning intentions

• Students will be able to explain how a rational number or integer quantity they used (for example, sensor thresholds, timing offsets, or displayed values) affects program behavior.
• Students will be able to add, subtract, and interpret signed values in contexts represented in their projects (number line reasoning).
• Students will be able to justify code changes involving signed multiplication/division outcomes when updating features or debugging.
• Students will be able to communicate their design decisions clearly during a short project pitch.

Success criteria

• I can describe a project feature using correct signed-value reasoning (distance from zero, direction, and magnitude).
• I can explain how changing a parameter (positive/negative) changes what the Micro:bit does.
• I can use addition/subtraction and additive inverse reasoning to explain my update or bug fix.
• I can explain (with evidence from my program) at least one improvement I would make with more time.

Curriculum links

• The Number System: addition and subtraction of rational numbers, represented on number line diagrams.
• The Number System: interpret sums of rational numbers in real-world contexts.
• The Number System: understand subtraction of rational numbers as adding the additive inverse.
• The Number System: understand division of integers and sign rules, and interpret quotients as rational numbers in context.
• The Number System: extend multiplication rules to rational numbers, interpret signed products in context.

Lesson structure (45 minutes)

1. 0–5 min · Launch & Goal Set. Teacher posts 3 choices on the board: Finalize / Extend / Peer Help, and shows a sample “60-second pitch” outline (what it does, how it works, what I’d improve). Students choose a work goal and write one “math-in-code” question they might need help with (e.g., “If I change -2 to 2, what changes?”).
2. 5–15 min · Workshop Build. Teacher circulates with a “What’s broken or incomplete?” check and quickly scans for opportunities to connect to signed values (adding/subtracting parameters, flipping signs, using divisions for scaling). Students work independently (or in pairs by choice) to implement one concrete progress step.
3. 15–22 min · Teacher Mini-Conferences (Round 1). Teacher pulls a small group (4–7 students) for rapid feedback: identify the next most important change, then ask one targeted math prompt tied to the project.

• Example prompts: “How does adding the additive inverse explain your fix?” “Where do you see direction or distance from zero in your behavior?” Students rotate into their mini-conference group and bring their code plus one screenshot/recording of current behavior.

4. 22–30 min · Peer Support & Debug Sprint. Teacher sets a clear protocol: peer explains using steps (1) what the program is supposed to do, (2) what it currently does, (3) where the signed value logic shows up, and (4) proposed change. Students pair up and run a 5-minute debug cycle, then swap roles.
5. 30–38 min · Teacher Mini-Conferences (Round 2) or Make Plans. Remaining students get one quick check-in, or teacher confirms pitch readiness. Teacher asks students to prepare a 60-second pitch draft with one “signed-value explanation” sentence (example starters: “My value becomes negative, which shifts my behavior…” “I used an additive inverse to change subtraction into addition…” “Multiplying two negatives should create a positive result, which matches my outcome.”). Students either continue coding or refine their pitch notes.
6. 38–45 min · Voluntary Showcase (Fast Demos). Teacher opens the floor for quick demos in 30–60 seconds each (volunteers only). While students demo, classmates listen for: (a) clear purpose, (b) one evidence-based explanation, (c) one improvement they’d make. Students demo or give supportive feedback using a single sentence frame: “Your project does ____, and your signed-value reasoning makes sense because ____.”

Resources

• Micro:bit devices with batteries/USB or classroom setup
• Laptops/tablets with the Micro:bit programming environment open
• Student project folders (or digital drive links)
• “60-second pitch” note cards or a one-page printable pitch template
• Number line mini-sheets (with marks for negative and positive values)
• Quick bug-fix checklist (Expected behavior vs. actual behavior vs. change made)
• Timer (project demo timing)

Assessment

• During mini-conferences, teacher checks for correct signed-value reasoning using one targeted question (addition/subtraction, additive inverse, sign rules for multiplication/division).
• Observation checklist during workshop: students articulate next steps and can connect one code parameter to its effect.
• Optional quick exit ticket (2 minutes, oral or written): “One signed value change I made is ____. Because of that, my program behavior ____. I can explain it using distance from zero / additive inverse / sign rule.”

Differentiation

• Support: Provide sentence starters for explanations (e.g., “When I added ____, the result moved __ units from zero.” “Subtracting __ is the same as adding __.” “A negative times a negative gives a positive.”).
• Support: Offer a “math-in-code” reference card with common transformations students might use (sign flip, subtraction-to-additive-inverse, scaling via multiplication/division).
• Extension: Students who finish early can add a second feature and include an additional signed-value justification in the pitch (for example, a threshold adjustment that requires reasoning about negative/positive behavior).
• EAL/SEN: Allow verbal explanations to count; provide visual number lines and encourage pointing to where the value lands (distance and direction).