Computer Science: Algorithms and Programming (KS2)
KS1CO-KS12-D002
Designing, writing and debugging programs that accomplish specific goals using sequences, selection, repetition, variables, and input/output; solving problems by decomposing them; using logical reasoning to explain algorithm workings.
National Curriculum context
At KS2, programming develops substantially in sophistication, moving from simple sequences to programs that use the fundamental control structures of computer science: sequence (instructions in order), selection (if-then-else decisions) and repetition (loops). The addition of variables - named storage locations that can hold and change values - enables much more powerful programs. Decomposition (breaking a problem into smaller, manageable parts) is introduced as a strategy for tackling complex programming challenges. The requirement to use logical reasoning to explain how algorithms work develops pupils' ability to analyse and communicate about code, not just to write it. Working with multiple programming languages, including at least one text-based language, broadens pupils' experience of how programming concepts are realised in different syntactic forms.
3
Concepts
2
Clusters
0
Prerequisites
3
With difficulty levels
Lesson Clusters
Understand algorithms and apply computational thinking
introduction CuratedAlgorithms and decomposition/computational thinking are tightly co-taught at KS2: understanding what an algorithm is (C001) is the prerequisite for decomposing problems into algorithms (C006), and C006 lists C001 in its co_teach_hints. Together they form the conceptual foundation before programming practice.
Design, write and debug programs using sequence, selection and repetition
practice CuratedProgramming with the three control structures (sequence, selection, repetition) is the practical application domain at KS2, distinct from the conceptual/algorithmic cluster. Pupils apply their understanding of algorithms by implementing them in programs.
Teaching Suggestions (6)
Study units and activities that deliver concepts in this domain.
HTML: My First Web Page
Computing Practical ApplicationPedagogical rationale
HTML introduces text-based coding in a forgiving context -- mistakes produce visible but non-catastrophic results (a tag in the wrong place makes text look wrong, not crash a program). Creating a web page is inherently meaningful: every website they use is made of HTML. Pupils see the direct relationship between code (text) and output (rendered page). This prepares for text-based programming languages.
Introduction to Python
Computing Practical ApplicationPedagogical rationale
The NC requires experience of at least one text-based programming language at KS2. Python is the standard choice because its syntax is readable and forgiving, it is used professionally (motivation for older pupils), and it connects directly to KS3 computing. Starting with simple programs (print statements, input, variables, if-else) and building to loops prepares pupils for secondary school programming.
Micro:bit Physical Computing
Computing Practical ApplicationPedagogical rationale
The micro:bit bridges digital programming and the physical world. Pupils program the micro:bit to respond to sensor inputs (button press, tilt, light level, temperature) and produce outputs (LED display, sound). This physical computing connects to DT (control in products) and Science (sensors measuring the environment). The block-based editor makes it accessible while the physical output makes it tangible.
Scratch Animation Project
Computing Practical ApplicationPedagogical rationale
Scratch is the de facto standard block-based programming environment for primary computing. Creating an animation requires sequencing, repetition (loops for animation), and event handling -- three key NC concepts in a single motivating project. The visual output gives immediate feedback on whether code is working correctly. This is typically the first substantial Scratch project at KS2.
Scratch Game Design
Computing Practical ApplicationPedagogical rationale
Designing a game in Scratch is the most motivating KS2 programming project and the one that demands the most sophisticated programming. A simple maze game requires all three control structures (sequence, selection, repetition), variables (lives, score, timer), and decomposition (separate scripts for player movement, enemy movement, collision detection, scoring). The project naturally teaches decomposition because it is too complex to write as a single script.
Scratch Interactive Quiz
Computing Practical ApplicationPedagogical rationale
An interactive quiz introduces selection (if-then-else) and variables (score tracking). The quiz asks a question, checks the answer using an if-block, and updates the score -- a complete input-process-output cycle. Creating quiz content on any subject reinforces cross-curricular knowledge. Variables are introduced naturally as 'the score counter'.
Concepts (3)
Algorithms
Keystone knowledge AI DirectCO-KS12-C001
An algorithm is a precise, unambiguous sequence of instructions for solving a problem or accomplishing a task. Algorithms are more general than programs: an algorithm describes what needs to be done, while a program is a specific implementation of an algorithm in a particular programming language. Algorithms must be correct (they produce the right output), precise (each step is unambiguous), and finite (they eventually reach a conclusion). At KS1 and KS2, pupils learn to write and recognise algorithms, understand their properties, and implement them as programs.
Teaching guidance
Begin with unplugged algorithm activities before moving to digital programming. Teach pupils to write step-by-step instructions for everyday tasks (making a sandwich, brushing teeth) to illustrate the precision required in algorithms. Use robot or turtle-following activities where pupils give instructions and observe the results of ambiguity or incorrect ordering. Discuss what happens when an algorithm has an error: the program does what we said, not what we meant. Introduce the idea of testing algorithms with different inputs to check they work in all cases.
Common misconceptions
Pupils may think that an algorithm is the same as a program; clarifying that an algorithm is the idea or plan, while a program is the specific coded implementation, is important. Pupils may not appreciate that algorithms need to be unambiguous; activities where deliberately ambiguous instructions lead to unexpected results make this vivid. The idea that a computer does exactly what it is told, rather than what we intended, is a fundamental shift in thinking that needs explicit attention.
Difficulty levels
Following a set of step-by-step instructions (an algorithm) to complete a task, understanding that the order matters.
Example task
Follow these instructions to draw a house: 1. Draw a square. 2. Draw a triangle on top. 3. Draw a rectangle door. 4. Draw two square windows. Did the order matter?
Model response: I followed each step in order and drew the house. The order matters because I needed the square first to know where to put the triangle roof on top.
Writing simple algorithms as a sequence of instructions for a familiar task, identifying when instructions are ambiguous or incomplete.
Example task
Write instructions for making a jam sandwich that a robot could follow exactly. Test your instructions with a partner.
Model response: 1. Pick up the bread bag. 2. Take out two slices. 3. Put them on the plate. 4. Pick up the knife. 5. Open the jam jar. 6. Put the knife in the jam. 7. Spread jam on one slice. 8. Put the other slice on top. When my partner tested them, they asked 'which side up?' for step 3 — I needed to add 'flat side up'.
Designing algorithms to solve problems, comparing different approaches and evaluating their efficiency.
Example task
Write two different algorithms for sorting five numbered cards into order. Which is more efficient?
Model response: Algorithm 1 (Checking pairs): Compare each pair of cards from left to right. If they are in the wrong order, swap them. Repeat until no swaps are needed. Algorithm 2 (Finding smallest): Find the smallest card and put it first. Find the next smallest and put it second. Continue until all are sorted. Algorithm 2 requires fewer comparisons for this small set, making it more efficient. But Algorithm 1 is simpler to understand.
Analysing the efficiency of algorithms, predicting how they perform with larger inputs, and explaining the concepts of algorithm design to others.
Example task
If Algorithm 1 (checking pairs) takes 10 comparisons to sort 5 cards, roughly how many might it take for 10 cards? Why does it take longer?
Model response: For 10 cards, it could take many more comparisons — maybe around 45 or more — because each pass through the list compares 9 pairs, and you might need many passes. The number of comparisons grows much faster than the number of cards. This is why computer scientists care about efficiency — a slow algorithm that works fine for 5 items might be too slow for 1000 items.
Delivery rationale
Computing concept — inherently digital subject with strong tool support.
Programming: Sequence, Selection and Repetition
skill AI DirectCO-KS12-C002
All programs are built from three fundamental control structures: sequence (instructions executed in order, one after another), selection (conditional branches where different instructions execute depending on a condition - if/then/else) and repetition (loops where instructions repeat a specified number of times or while a condition holds). These three structures are sufficient to express any computable algorithm, and mastery of them is the core of programming competence. At KS2, pupils learn to use all three structures in their programs, developing increasingly sophisticated and efficient code.
Teaching guidance
Introduce each control structure separately before combining them. Use visual block-based programming environments (Scratch, Blockly) initially to reduce syntax barriers. Progress to text-based languages at upper KS2 to develop more precise understanding of programming syntax. Always connect programming tasks to a genuine purpose: a game, an animation, a simulation. Teach debugging systematically: read the code line by line, trace the execution, identify where actual behaviour diverges from expected behaviour. Celebrate debugging success as much as successful first attempts.
Common misconceptions
Pupils often use loops incorrectly, either not using them when repetition is present (writing the same instruction multiple times) or using them in inappropriate contexts. Explicit comparison of repetitive code versus loop code makes the efficiency benefit clear. Selection (if/then/else) is conceptually more demanding; pupils may write conditions that cannot be true, or miss the else case. Tracing through conditional code step by step makes the logic visible.
Difficulty levels
Creating a simple program using sequence — a series of instructions executed in order — using a block-based programming environment.
Example task
Program the sprite to walk forward 100 steps, say 'Hello!' and then turn around.
Model response: I used three blocks: 'move 100 steps', 'say Hello! for 2 seconds', 'turn 180 degrees'. The sprite walked, spoke and turned around.
Using selection (if/then) and repetition (loops) in programs to create more complex behaviour.
Example task
Program a character that walks forward and turns when it reaches the edge of the screen. Use a loop and an if statement.
Model response: I used a 'forever' loop containing: 'move 10 steps', then 'if touching edge then turn 180 degrees'. The character bounces back and forth across the screen without stopping. The loop repeats the instructions and the if-statement checks for the edge each time.
Combining sequence, selection and repetition to create programs that solve problems or meet a design brief, using variables to store and change data.
Example task
Create a quiz program that asks three questions, uses a variable to keep score, and gives a different message depending on the final score.
Model response: I created a variable called 'score' set to 0. For each question, I used 'ask' and checked the answer with an if-statement. If correct, I increased score by 1. At the end, I used selection: if score = 3, say 'Perfect!'; if score >= 1, say 'Well done!'; else say 'Try again!'. The program uses sequence (question order), selection (checking answers) and repetition (I could put questions in a loop).
Designing modular programs using procedures or functions, explaining how abstraction makes programs easier to understand and maintain.
Example task
Refactor your quiz program so each question is handled by a reusable procedure. Why is this better?
Model response: I created a procedure called 'ask_question' that takes a question and correct answer as inputs. It asks the question, checks the answer, and updates the score. My main program just calls this procedure three times with different questions. This is better because if I want to change how questions work, I only change the procedure once instead of changing code in three places. It is also easier to add more questions.
Delivery rationale
Computing concept — inherently digital subject with strong tool support.
Decomposition and Computational Thinking
skill AI DirectCO-KS12-C006
Computational thinking is a set of problem-solving approaches that involve breaking problems down (decomposition), identifying patterns (pattern recognition), focusing on the most relevant information (abstraction) and developing step-by-step solutions (algorithm design). Decomposition - breaking a complex problem into smaller, manageable sub-problems - is particularly important in programming, as it enables pupils to tackle problems that would otherwise be too large to address as a whole. At KS2, pupils apply decomposition to design programs and to plan complex digital projects.
Teaching guidance
Model decomposition explicitly when setting programming tasks: show how a complex program can be broken into components (an animation with a background, a character, sound, score). Ask pupils to plan their program structure before coding. Teach the use of procedures and functions as a way of organising decomposed code. Practice decomposition in non-computing contexts: planning an event, organising a research project. Connect decomposition to the design stage of the design-make-evaluate cycle. Use flowcharts and pseudocode to represent decomposed algorithms before implementing them.
Common misconceptions
Pupils may attempt to solve programming challenges as a single, undivided problem rather than decomposing them. Modelling the decomposition process explicitly, and requiring pupils to plan before coding, develops this habit. Abstraction (ignoring irrelevant detail) can be conceptually challenging; concrete examples of what to include and what to leave out in specific contexts help. Pupils may not see the connection between computational thinking and problem-solving in other domains; deliberate cross-curricular examples broaden the concept.
Difficulty levels
Breaking a simple problem into smaller, more manageable parts (decomposition).
Example task
You want to plan a birthday party. Break this big task into smaller tasks.
Model response: 1. Choose a date. 2. Make a list of who to invite. 3. Send invitations. 4. Choose food and drinks. 5. Plan games and activities. 6. Decorate the room. Breaking it into small steps makes it less overwhelming and I can do one thing at a time.
Applying decomposition, pattern recognition and abstraction to solve problems: identifying repeated patterns and focusing on the most important information.
Example task
Look at these five animals: cat, dog, rabbit, goldfish, parrot. Group them by a pattern, then describe each group using one word (abstraction).
Model response: Pattern 1: cat, dog, rabbit — they are all mammals (fur, legs). Pattern 2: goldfish — lives in water (fish). Pattern 3: parrot — has feathers (bird). The abstraction removes specific details (colour, size, breed) and focuses on the key category. This is what computational thinking does — it focuses on what matters for the problem.
Applying all aspects of computational thinking (decomposition, pattern recognition, abstraction, algorithm design) to solve a complex problem systematically.
Example task
Design a solution for automatically sorting recycling into three bins: paper, plastic and metal. Use computational thinking.
Model response: Decomposition: break it into detecting material type, moving the item to the correct bin, and counting items sorted. Pattern recognition: paper is light and flexible, plastic is light but rigid, metal is heavy and cold. Abstraction: we only need to know the material type — colour, size and shape don't matter. Algorithm: 1. Weigh the item. 2. If heavy, it's metal — move to metal bin. 3. If light, test flexibility. 4. If flexible, it's paper — move to paper bin. 5. If rigid, it's plastic — move to plastic bin.
Evaluating the effectiveness of computational thinking solutions, identifying limitations and suggesting improvements, and explaining how these approaches are used in real-world computing.
Example task
Our recycling sorting algorithm would fail for some items. What are its limitations? How could we improve it?
Model response: Limitations: some items combine materials (a juice carton is paper and plastic), weight alone doesn't reliably distinguish materials (a thick sheet of paper could be as heavy as thin plastic), and the algorithm doesn't handle glass or food waste. Improvements: add a material sensor instead of just weight, add more categories, use machine learning to recognise items from images like real sorting facilities do. This shows that computational thinking produces a first solution that then needs testing and refining — just like real software development.
Delivery rationale
Computing concept — inherently digital subject with strong tool support.