Earlier you used the four steps of computational thinking to break a build down and make it. One of those steps was algorithms: writing the steps of a solution in order.
Today you learn two ways coders write an algorithm down before they touch a block: pseudo-code (plain steps in order) and a flow chart (the same plan drawn as boxes and arrows). You will plan a small quiz, then build it in Scratch and check the program matches the plan.
Quick recap: ask who can name the four computational-thinking steps already covered. Steer them to algorithms as today's focus. Keep this under three minutes so the planning work gets the time.
An algorithm is a clear set of steps that solve a problem. Coders write it down before they build, so anyone reading the plan knows exactly what should happen, and so they know exactly what to build.
Today you will write the same plan two ways:
Here is the plain-English idea you will plan and build today:
A sprite asks for a name and greets them. It then asks how many counties are in Ireland. If the answer is 32, the score goes up by 1 and it says "Correct!". If not, it says "Not quite".
Here is that idea as sample pseudo-code you can imitate:
The flow chart shown on this step, just below, shows the same plan drawn as shapes. Notice the diamond is the decision: yes goes one way, no goes the other.
Work the sample live on the board for one or two minutes so students see the words and the shapes side by side. Teach shapes only as they appear: oval for START/END, rectangle for an action, diamond for the yes-or-no check, arrows for order. Do not lecture a full shape legend up front.
Point at the diamond as the decision point. Common misconception: students write vague steps like "check the answer". Push for precision: "if answer equals 32".
Do not open Scratch yet. The point of this step is the plan, not the blocks. Keep the whole step tight so writing starts in the next step while the sample is still on screen.
Turn the quiz idea into a plan on paper or in a notes file. Use the sample as a model.
Suggested timing: most of the ten minutes on pseudo-code and flow chart; push anyone who has two solid lines into Scratch so something runs before the full build step.
Model the first two pseudo-code lines on the board if the class stalls, then stop and let them finish. Circulate for vague steps ("do the quiz") and push for testable lines ("if answer = 32").
Core finish line for everyone: SET score, counties question, plus the diamond decision path. Name and greeting are worth including but must not block slower writers from reaching the decision.
Do not wait for whole-class plans to be finished before anyone opens Scratch; the early Scratch start is the default path once two solid lines exist, not a rare extra.
Build your plan in Scratch and check the program matches it. This is testing and debugging: you are checking the program against the plan and fixing mismatches.
Core finish line: counties question, if-else that runs both paths, and a quick line-by-line match against your plan. Name and greeting only if you still have time.
Keep the plan beside the blocks. The learning is the match between plan and program, not a polished quiz.
Open the step with a 60-second whole-class rebuild of the diamond path only on the board (if-else, both branches), then send them back. Do this early, not only when several are stuck.
Core finish line for everyone: counties question + if-else both paths + quick match. Name and greeting are if-time only.
If score is already above 0 from an earlier run, have them set score to 0 at the start of the script so the plan and the program still match.
For the match check, pick one volunteer plan/program pair and walk two lines together as a class beat so everyone sees what "matches" looks like, then let them finish their own check.
Predict beat once a student has blocks on screen: Before you click the green flag, what should happen if someone types 26?
Students who finish early can tidy the name/greeting path or add a costume change on correct, still matching the plan. If anyone is fully done with time to spare, they can start choosing which one menu add-on they will write into their plan in the next step.
Required for everyone: extend your plan, swap with a classmate, and flag one unclear step. Building their plan is only if you finish those three with time left.
Before → after example if you choose lives (keep the original path and add the new bits):
Before (fragment):
After (full short plan a classmate can build):
Save your Scratch project the way your teacher just showed you before you stop.
Pre-assign pairs before this step starts so swap logistics do not eat the minutes. Put a visible 4-minute timer on the extend rewrite only, then call the swap.
Required finish line for everyone: extend + swap + one precision flag. State a hard stop after the precision note so nobody rushes past the LO. Peer build is strictly early-finisher work after that hard stop.
Constrain everyone to one menu option and a short rewritten plan (use the before → after lives example on the board if needed). No new flow chart in this step; pseudo-code only keeps the invent phase short.
Watch for students who "fix" a vague plan instead of flagging it; the flag is the learning. Cap any peer build at getting the decision diamond to run.
If someone has no partner, they can work from a short plan you write on the board (keep it deliberately slightly vague on one step so the precision point still lands).
Before they finish, show the class save routine live (for example File, Save to your computer as QuizPlan_TheirName in the class folder). Leave about two minutes at the end for the save.
You're previewing this lesson. Get full access to this lesson and hundreds more — each one ready to teach, with interactive activities, printable resources and pupil progress tracking built in.