Scratch — Year 6 Teachers' Guide

Lessons

Total time

Objectives

Mini-projects

Final game

🔍

No results found. Try a different search term.

Lesson Plans

Key point

Scratch uses coloured blocks that snap together like puzzle pieces to build programs. There is no typing required — this makes it accessible to all pupils from the very first lesson.

Learning objectives

Navigate the Scratch interface: Stage, Sprite pane, Block palette, Scripts area
Add, rename, and delete sprites and backdrops
Connect Motion and Looks blocks to make a sprite move and speak
Use the Green Flag and Stop buttons correctly

Lesson structure — 60 minutes

Hook (5 min) — Show a community Scratch project on the board
Interface tour (10 min) — Live demo; pupils label parts on a worksheet
Guided build (20 min) — Make the cat move 10 steps and say "Hello!"
Independent explore (20 min) — Pupils customise sprite, costumes, backdrop
Share & reflect (5 min) — 2–3 pupils share; class spots one new thing each

Key Scratch blocks this week

move 10 steps turn ↻ 15° go to x:0 y:0 say Hello! for 2 secs set size to 100% switch costume when 🚩 clicked

🐱 Mini-project — My Animated Pet

Choose or draw a sprite
Make it walk from left to right across the stage
Make it say something when it reaches the edge
Extension: add a backdrop and a second sprite

Teacher note

Emphasise the colour-coding — Motion blocks are always blue, Looks always purple. This helps pupils find blocks quickly throughout the whole unit.
The most common issue in week one: pupils forget to click the green flag. Always demonstrate this at the start of each lesson.
For pupils who finish early: challenge them to add if on edge, bounce. For those who struggle: provide a printed step-by-step card and pair them with a buddy.

Key point

Scratch is event-driven — code only runs when something triggers it, such as pressing a key, clicking the flag, or receiving a broadcast message. Multiple scripts can run at the same time.

Learning objectives

Understand event-driven programming: code runs in response to triggers
Use when key pressed blocks to move sprites with arrow keys
Understand the Scratch coordinate system (x/y axis; centre is 0, 0)
Use broadcast and when I receive to coordinate multiple sprites

Lesson structure — 60 minutes

Warm-up (5 min) — "If I press up, what should happen?" — real-world input/output
Coordinate plane (10 min) — Sticky notes on a whiteboard grid at given (x, y) values
Guided build (20 min) — 4-direction keyboard controller built together
Broadcast demo (10 min) — Sprite 1 broadcasts "game-start"; sprite 2 reacts
Independent build (10 min) — Pupils add a second sprite that receives a broadcast
Reflect (5 min) — Why is broadcasting useful?

Key Scratch blocks this week

when [up arrow] key pressed change x by 10 change y by 10 point in direction 90 if on edge, bounce broadcast [message1] when I receive [message1]

Code pattern — 4-direction keyboard controller

// Attach one "when key pressed" block for each direction
when [up arrow] key pressed
change y by 10

when [down arrow] key pressed
change y by -10

when [left arrow] key pressed
change x by -10

when [right arrow] key pressed
change x by 10
              

⚡ Mini-project — Chase Game Starter

Player sprite controlled by arrow keys
Second sprite moves when "game-start" broadcast is received
Both sprites reset to start positions on green flag
Extension: add a third sprite that moves randomly

Common misconception

Pupils often think "when key pressed" blocks take turns. Show them that Scratch runs multiple scripts simultaneously — this is event-driven parallelism. Use the analogy of several people each waiting by a different phone, ready to pick up only when their specific number rings.

Key point

All programs use the same three structures: sequence (do this, then this), selection (if this, do that), and iteration (repeat). Pupils already know sequence — this lesson adds the other two.

Learning objectives

Distinguish between repeat N, repeat until, and forever loops
Use if/else blocks to make decisions
Use sensing blocks: touching colour, touching sprite, mouse position
Combine conditions using Boolean and / or / not

Lesson structure — 60 minutes

Unplugged warm-up (8 min) — "Simon Says" as a loop: "repeat 3 times: jump"
Loop demo (10 min) — Draw a square with repeat 4; a circle with forever
Conditional demo (12 min) — Add collision detection to the chase game from Week 2
Independent build (25 min) — Pupils add win/lose conditions to their own project
Debug challenge (5 min) — Show a broken script; pupils identify the bug

Key Scratch blocks this week

repeat (10) forever repeat until <> if <> then if <> then / else touching [Sprite]? touching color [■]? mouse down? <> and <> not <>

Code pattern — Collision detection

// Add this to your player sprite
when 🚩 clicked
forever
if <touching [Enemy]?> then
broadcast [game-over]
stop [this script]
end
end
              

🔁 Mini-project — Maze Runner

Draw a simple maze backdrop with a specific wall colour
Player navigated with arrow keys; forever loop checks for wall collision
Touching the wall colour sends the player back to the start
Touching the goal sprite broadcasts "you-win" and plays a sound
Extension: show a countdown timer on screen

Discussion point

Ask pupils: "When would you NOT want a forever loop?" Lead them to discover that forever is ideal for continuous monitoring (checking collisions every frame) but repeat N is better for controlled, finite animations. This builds real computational thinking around efficiency.

Key point

A variable is a labelled box that stores a value which can change while the program runs. A variable called score starts at 0 and goes up each time the player collects something — the label stays the same; the value inside changes.

Key point — initialisation

Always set every variable to its starting value under when green flag clicked. If you skip this, the second play-through will begin with leftover values from the previous run — one of the most common bugs beginners encounter.

Learning objectives

Describe a variable as a named container for a changing value
Create variables scoped to all sprites or this sprite only
Use set variable to, change variable by, and read its value
Build a working score counter and a lives system
Show and hide variables on the stage display

Lesson structure — 60 minutes

Analogy hook (5 min) — Variable = a named box on a shelf. Draw it on the board.
Score demo (15 min) — Create "score"; increment on coin touch; reset on green flag
Lives system (15 min) — Create "lives"; decrement on enemy touch; game over at 0
Independent build (20 min) — Pupils integrate score + lives into their own project
Reflection (5 min) — "What other data might a game need to remember?"

Key Scratch blocks this week

set [score] to (0) change [score] by (1) show variable [score] hide variable [score] timer reset timer

Code pattern — Score and lives system

// ── Initialise on green flag ──
when 🚩 clicked
set [score] to 0
set [lives] to 3

// ── Collecting a coin ──
when I receive [coin-collected]
change [score] by 1

// ── Hit by enemy ──
when I receive [player-hit]
change [lives] by -1
if (lives) = 0 then
broadcast [game-over]
end
              

Scope — all sprites vs this sprite only

All sprites — any sprite can read or change this variable. Use for: score, lives, level, game state.
This sprite only — private to one sprite. Use for: that sprite's individual speed, health, or animation frame.
Discussion: Why might sharing a variable cause bugs? (Two sprites both accidentally changing score.)

Key point

A list is like a variable, but instead of holding one value it holds many — like a numbered shopping list. A list called "High Scores" can store every score a player has ever achieved, one per line.

Key point — cloning

Cloning lets one sprite create identical copies of itself while the game is running. This is how you spawn multiple enemies or falling objects without having to manually add hundreds of sprites to the project.

Learning objectives

Explain the difference between a variable (one value) and a list (many values)
Add, delete, and read items from a list; find its length
Use the clone system: create clone, when I start as a clone, delete this clone
Build a falling-objects catcher game using clones

Lesson structure — 60 minutes

List analogy (5 min) — A price tag (one value) vs a shopping list (many values)
List demo (10 min) — Store pupil names; use a loop to say each one
Clone demo (15 min) — Original sprite hides; creates clones falling from random x positions
Build: falling objects (25 min) — Catcher game using clones for falling items
High score extension (5 min) — Demo adding score to a list

Key Scratch blocks this week

add [thing] to [list] delete (1) of [list] item (1) of [list] length of [list] [list] contains [x]? create clone of [myself] when I start as a clone delete this clone pick random (1) to (10)

Code pattern — Falling objects with clones

// ── Original sprite: spawner ──
when 🚩 clicked
hide
forever
create clone of [myself]
wait (1) seconds
end

// ── Each clone: fall and detect ──
when I start as a clone
show
go to x: (pick random -200 to 200) y: 180
repeat until <(y position) < -180>
change y by -5
if <touching [Catcher]?> then
change [score] by 1
delete this clone
end
end
delete this clone
              

Did you know?

Each clone inherits the original sprite's variable values at the moment of cloning. However, variables set to "this sprite only" become independent per clone after creation — each clone can track its own falling speed. This is the beginning of thinking about objects in programming.

Key point — persisting state

Persisting state means saving data so it survives beyond a single session. When you close a game and your high score is still there the next day — that is persisted data. Scratch cloud variables (☁) do exactly this by storing a number on MIT's servers.

Key point — state machines

A state machine controls which "screen" a game is on at any moment. The game is always in exactly one state: menu, playing, or game-over. A variable called gameState holds the current state; broadcasts and backdrop switches move between them.

Learning objectives

Explain what "persisting state" means and give a real-world example
Implement a simple state machine using a gameState variable
Use cloud variables (☁) to share a high score between players
Add level progression: increase difficulty using a level variable
Plan a project on paper before coding (state diagram)

Lesson structure — 60 minutes

Discussion (8 min) — "Have you ever lost your game progress? Why does that happen?"
State machine demo (15 min) — Build the 3-screen game flow together
Cloud variable demo (7 min) — Show the ☁ symbol; sync across browsers live
Final project build (25 min) — Add menu, game over screen, and high score to Week 5 game
Showcase (5 min) — Share links; class votes on favourite feature

Key Scratch blocks this week

☁ [high score] set [gameState] to [menu] switch backdrop to [Menu] when backdrop switches to [Menu] set [level] to (1) change [level] by (1) stop [all]

Code pattern — State machine game flow

// ── Initialise ──
when 🚩 clicked
set [gameState] to "menu"
switch backdrop to [Menu]

// ── Menu screen: wait for space bar ──
when backdrop switches to [Menu]
wait until <key [space] pressed?>
set [score] to 0
set [lives] to 3
set [gameState] to "playing"
switch backdrop to [Game]

// ── Game over: save cloud high score ──
when I receive [game-over]
set [gameState] to "game-over"
if (score) > (☁ high score) then
set [☁ high score] to (score)
end
switch backdrop to [Game Over]

// ── Level progression ──
when I receive [level-complete]
change [level] by 1
set [enemy speed] to (5 + level)
              

Cloud variables — safety note

Cloud variables are stored publicly on MIT's servers and are visible to anyone who runs the project.
They only store numbers — strings are not supported.
Scratch requires users to be aged 13+ for cloud variables — demonstrate this feature using your teacher account and have pupils observe rather than use it themselves.
Never store names, ages, or school information in cloud variables.

🎮 Final Project — My Complete Game

Pupils submit a complete game demonstrating all six weeks of learning:

Menu screen — backdrop switch, press space to start
Keyboard-controlled player — events and motion
Collision detection — sensing and conditionals
Score and lives — variables correctly initialised and updated
Enemies or collectibles — cloning pattern
Game over screen — state machine with backdrop switch
Extension: Level progression — level variable increases difficulty
Extension: Cloud high score — demonstrated via teacher account

Design before you code

Have pupils sketch their game on paper first: what screens exist? What variables are needed? Draw arrows between screens showing what triggers each transition. This state diagram maps directly to the code they will write and builds the habit of planning that professional software engineers use every day.

Assessment Rubric

Criterion	Beginning	Developing	Meeting	Exceeding
Programming concepts	Uses only motion and looks blocks; no events or loops	Uses events and at least one loop; some conditionals present	Correctly uses loops, conditionals, events, and variables throughout	Uses lists, cloning, broadcasts, and a state machine effectively
Variables & state	No variables; or variables used but not initialised	Uses 1–2 variables but does not reset them correctly on green flag	Multiple variables correctly initialised and updated; game logic works as intended	Variables scoped appropriately; state machine controls game screens; cloud high score attempted
Game design	Collection of unrelated scripts; no clear goal or player feedback	Clear goal but game is unbalanced or missing a win/lose condition	Playable game with clear win/lose conditions and feedback to the player	Polished game with multiple levels, increasing difficulty, and a satisfying experience
Debugging & reflection	Cannot describe what scripts do; relies entirely on the teacher	Can describe most scripts but struggles to find bugs independently	Can explain all scripts and fix common bugs with minimal support	Systematically debugs others' code; explains what each variable stores and why

Resources

🌐

Scratch — scratch.mit.edu
The main platform. Create a teacher account to manage pupil accounts, see their projects, and enable cloud variables. Free forever.
🎓

Scratch Teacher Accounts — scratch.mit.edu/educators
Create a class and manage pupil accounts without requiring individual email addresses. Essential for primary school use under GDPR.
📦

Creative Computing Guide — ScratchEd, Harvard
A full curriculum guide with unplugged activities, worksheets, and lesson plans. Developed by Harvard's Graduate School of Education and freely downloadable.
🏫

Code.org — CS Fundamentals
Complementary unplugged activities that reinforce loops and conditionals without a computer — useful for mixed-ability groups or cover lessons.
🛡️

Online safety
Use Scratch Teacher Accounts so pupils never enter a real name, age, or email. Remind the class that cloud variables are public — never store personal information in them.
🖨️

Print this guide
Press Ctrl + P (or Cmd + P on Mac) — all lesson plans expand automatically for full-page printing. Print individual week panels and laminate them as desk reference cards.

Curriculum alignment — England National Curriculum KS2 Computing (DfE 2014)

This unit addresses: "design, write and debug programs that accomplish specific goals… use sequence, selection, and repetition in programs… use logical reasoning to explain how some simple algorithms work… understand computer networks including the internet."

Scratch Programming — Year 6

Lesson Plans

Learning objectives

Lesson structure — 60 minutes

Key Scratch blocks this week

Learning objectives

Lesson structure — 60 minutes

Key Scratch blocks this week

Learning objectives

Lesson structure — 60 minutes

Key Scratch blocks this week

Learning objectives

Lesson structure — 60 minutes

Key Scratch blocks this week

Scope — all sprites vs this sprite only

Learning objectives

Lesson structure — 60 minutes

Key Scratch blocks this week

Learning objectives

Lesson structure — 60 minutes

Key Scratch blocks this week

Assessment Rubric

Resources