Algorithmic Thinking in
Computational Thinking
This teacher training module prepares educators to confidently teach the Algorithmic Thinking sub-skill under Computational Thinking for Class 6, as defined in the CBSE CT & AI Curriculum 2026–27. Algorithmic Thinking is the ability to follow, analyse, design, and apply step-by-step procedures with precision — the direct cognitive precursor to programming, data processing, and AI model logic.
At Class 6 level, students move beyond single-rule procedures into multi-layered algorithms involving conditional branches, iterative steps, and the critical ability to distinguish necessary instructions from redundant ones.
- Understand what Algorithmic Thinking means across six problem contexts at Class 6 level.
- Map all 6 LO sub-areas to worked trace examples showing algorithm execution step by step.
- Practise 5 classroom activities that teach algorithm following, analysis, and design as distinct skills.
- Apply a rubric that distinguishes between following an algorithm correctly and designing one independently.
- Identify and address the most persistent student errors in multi-step algorithmic reasoning.
| Module Component | Duration | Format |
|---|---|---|
| Section 1: Overview & Curriculum Context | 20 min | Presentation + Discussion |
| Section 2: Unpacking the Learning Outcomes | 30 min | Trace Examples + Group Analysis |
| Section 3: Pedagogical Strategies | 25 min | Demonstration |
| Section 4: Classroom Activities (Hands-on) | 65 min | Workshop |
| Section 5: Assessment Strategies | 25 min | Rubric Practice |
| Section 6: Common Misconceptions & FAQs | 15 min | Q&A |
Class 6 students must be able to follow, analyse, and apply multi-layered rules and procedures. This three-level expectation — follow → analyse → apply — maps directly to Bloom’s taxonomy and defines three distinct instructional targets within a single LO. Each sub-area below has a worked trace example showing what this looks like in practice.
Execute given steps precisely
Identify errors, redundancy, order
Design or modify an algorithm
Most Class 6 tasks require all three levels within a single problem. Assessment must reflect which level each question targets.
| # | LO Area | What it looks like in Class 6 | Bloom’s Level |
|---|---|---|---|
| LO 1 | Number sequences — combined operations & logical conditions | A rule like “If the current term is even, divide by 2; if odd, multiply by 3 and add 1.” Students trace 8 steps, then analyse when (and whether) the sequence terminates | Apply / Analyse |
| LO 2 | Grid movement — direction, distance, turns, path constraints | Execute a set of movement instructions on a 6×6 grid (FORWARD 2, TURN RIGHT, FORWARD 3…) and identify the final position and facing direction; analyse whether an alternate route reaches the same endpoint | Apply / Evaluate |
| LO 3 | Step-wise changes — values increasing/decreasing by rules | A value-change machine: “Input 20. Apply Rule A (subtract 3) then Rule B (if result is odd, add 1; if even, halve). Repeat 5 times. What is the output?” Students trace and build a Trace Table | Apply / Analyse |
| LO 4 | Multi-step instructions — swaps, shifts, transfers, rearrangements | Cards labelled 1–5 placed in a row. Execute: Swap positions 1 and 3 → Shift all cards one place right (last card goes to position 1) → Swap positions 2 and 4. What is the final order? | Apply |
| LO 5 | Ordering using multiple attributes or clues | Five students are ranked using two clues simultaneously (height and age). Students design the algorithm (which attribute to sort by first, what to do in a tie) and execute it to produce the final order | Analyse / Create |
| LO 6 | Logical flow — necessary vs redundant information | An 8-step algorithm is given for a task. Two steps are redundant (produce no change to state). Students identify them, explain why they are redundant, and rewrite the minimal algorithm | Evaluate / Create |
Classroom Trace Example Bank:
| Step | Current Value | Condition | Operation | Next Value |
|---|---|---|---|---|
| 1 | 12 | Even | ÷ 2 | 6 |
| 2 | 6 | Even | ÷ 2 | 3 |
| 3 | 3 | Odd | ×3 + 1 | 10 |
| 4 | 10 | Even | ÷ 2 | 5 |
| 5 | 5 | Odd | ×3 + 1 | 16 |
| 6 | 16 | Even | ÷ 2 | 8 |
| Instruction | Operation | Pos 1 | Pos 2 | Pos 3 | Pos 4 | Pos 5 |
|---|---|---|---|---|---|---|
| Start | — | A | B | C | D | E |
| Step 1 | Swap pos 1 & 3 | C | B | A | D | E |
| Step 2 | Shift right; last → pos 1 | E | C | B | A | D |
| Step 3 | Swap pos 2 & 4 | E | A | B | C | D |
| Instruction | Row | Col | Facing |
|---|---|---|---|
| Start | 5 | 1 | N |
| FWD 3 | 2 | 1 | N |
| TURN RIGHT | 2 | 1 | E |
| FWD 2 | 2 | 3 | E |
| TURN LEFT | 2 | 3 | N |
| FWD 1 | 1 | 3 | N |
Algorithmic Thinking at Class 6 requires teachers to make procedural execution visible, auditable, and improvable. The following strategies are most effective for this LO, particularly when students must move from following algorithms to analysing and designing them.
| Strategy | Description | Best for LO |
|---|---|---|
| Trace Table Method | Students record the state of all variables at every step in a structured table. This makes implicit computational state explicit and auditable. The trace table is the single most important tool for algorithmic thinking at this level. | LO 1, LO 3, LO 4 |
| Human Computer (Role Play) | One student acts as the “computer” executing instructions exactly as written — no interpretation, no shortcuts. Another student acts as the “programmer” giving instructions. A third acts as “debugger” watching for errors. Roles rotate. Makes precision and ambiguity viscerally clear. | LO 2, LO 4, LO 5 |
| Broken Algorithm Repair | Students are given an algorithm with a deliberate error (wrong step order, missing step, or extra redundant step) and a known correct output. They must trace, find the fault, and fix it — building debugging as a skill. | LO 6, All LOs |
| Minimal Algorithm Challenge | After solving a problem, students are challenged to solve it with fewer steps. Encourages algorithmic efficiency thinking — recognising that more instructions ≠ better algorithm. | LO 6 |
| Predict-Before-Execute | Before tracing an algorithm, students predict the final state/output. They then execute step by step and compare. Prediction errors are the richest discussion points — they reveal exactly where algorithmic intuition breaks down. | LO 1, LO 2, LO 3 |
| Algorithm Swap (Peer Review) | Students write their own algorithm for a task, then swap with a partner. The partner executes it exactly as written — no assumed intent. Misunderstandings reveal ambiguity, missing steps, and imprecise language in the original algorithm. | LO 5, LO 6 |
The Human Computer activity is the highest-impact demonstration in this module. Set it up live during training: ask one participant to “execute” instructions for making a cup of tea — interpreted literally, word-for-word. The results are both humorous and deeply instructive. This experience permanently shifts how teachers understand the difference between natural language and algorithmic precision. Plan 10–12 minutes and allow participants to debrief the experience before moving on.
Each activity below progresses through the three levels: Follow → Analyse → Apply. All activities are unplugged or low-resource and directly classroom-ready.
Students receive a “Value Machine” card describing a 2-rule conditional algorithm (Rule A + Rule B applied in sequence, repeated N times). They (a) complete the Trace Table for the given input, (b) determine what input would be needed to produce a specified output after 4 steps, and (c) identify at which step — if any — the value stabilises or enters a loop. Part (c) introduces the concept of algorithm termination.
- Value Machine card sets (3 difficulty levels: 2-rule, 3-rule, conditional-branch)
- Blank Trace Table template (Step / Current Value / Condition / Operation / Next Value)
- Optional: physical “input-output” machine prop (a decorated box)
- Insist every student completes the Trace Table row-by-row — no mental shortcutting allowed.
- Ask: “Did the algorithm terminate? How many steps? Would it always terminate for any input?”
- For part (b), students must work the Trace Table backwards — a powerful reverse-engineering challenge.
- Connect: “This is how computer programs with IF-THEN-ELSE logic work. Your trace table IS a program execution log.”
Partners work on a 7×7 grid with some cells marked as “blocked.” One partner has a destination card (unknown to the other). They write a set of movement instructions for their partner to execute. The executing partner traces the path, marks each position, and records the state at each step. If the path hits a blocked cell, the algorithm is “faulty” and must be debugged and rewritten. Partners then swap roles.
- Printed 7×7 grid sheets (unique blocked-cell layouts per group)
- Instruction card template (FORWARD N / TURN LEFT / TURN RIGHT / BACKWARD N)
- Coloured markers for tracing path
- Position State Tracker (Row / Col / Facing columns)
- Require students to record facing direction at every step — not just position. This is the most commonly skipped piece of state.
- When a path hits a blocked cell: “Don’t restart. Identify exactly which instruction caused the error and fix only that instruction.”
- Extension: “Write the shortest possible instruction sequence to reach the destination. Can you do it in fewer than N steps?”
- Connect: “This is how robots and autonomous vehicles navigate — they follow an instruction set and update their position state after each step.”
Each group has 5 physical cards (labelled 1–5 or A–E) arranged in a starting order. They receive a 5-step algorithm of SWAP, SHIFT, and REVERSE instructions. Each student in the group takes one instruction at a time, physically moves the cards, and the group records the state in their State Trace Table after each step. The final challenge: given the final output shown on a card, write the reverse algorithm that transforms the output back to the original starting order.
- 5 physical cards per group (numbered or lettered; different colours help)
- Algorithm instruction card (5 steps: mix of SWAP, SHIFT, REVERSE)
- State Trace Table (Step / Pos1 / Pos2 / Pos3 / Pos4 / Pos5)
- Reverse Algorithm Challenge card (for extension)
- The physical card manipulation is essential — do not replace it with a worksheet for the first attempt. Kinesthetic execution builds intuition that a diagram cannot.
- The reverse algorithm challenge is a deep extension. Discuss: “Is the reverse always possible? What property of an algorithm makes it reversible?”
- Connect: “SWAP and SHIFT are the two fundamental operations used in sorting algorithms. Every time your phone sorts photos by date, it is doing millions of swaps.”
Students receive a set of 6 “person cards,” each with 3 attributes (e.g., age, height, score). They must first design the sorting algorithm — deciding the primary sort key, secondary key (for ties), and tertiary key. They then execute their algorithm on the cards and produce the final ranked order. Two pairs with different algorithm designs then compare their outputs and discuss: do different valid algorithms produce different results? When does the algorithm design choice matter?
- Printed person attribute cards (6 per pair, 3 attributes each)
- Algorithm Design Template (Primary key / Secondary key / Tie-break rule)
- Comparison sheet for class debrief (recording different pairs’ final orders)
- Design the card set to have at least 2 deliberate ties on the primary key — so the secondary key is always needed.
- Ask: “Did two pairs produce different outputs? Whose algorithm is correct? Can both be correct?”
- Establish the key insight: an algorithm is correct relative to its specification. The specification (which attribute to sort by first) is a design choice — and it matters enormously.
- Connect: “When Google ranks search results, it uses hundreds of sorting attributes with a priority order. Every ranking system is an algorithm like this one.”
Students receive a 9-step algorithm for a clearly defined task (e.g., finding the largest number in a list, or sorting 3 objects). Two steps are redundant (they execute without changing the state), one step is in the wrong position, and one step is missing. Students must: (a) trace the algorithm, (b) identify and justify each redundant step, (c) find and fix the ordering error, and (d) add the missing step. Finally, they rewrite the corrected, minimal algorithm in exactly the right order.
- Printed Algorithm Audit card (9-step flawed algorithm)
- Trace Table for executing the algorithm
- Algorithm Rewrite template (blank numbered steps)
- Answer key for teacher (kept hidden until debrief)
- Do not reveal which steps are redundant beforehand — students must discover this through tracing.
- Require written justification for each redundant step: “This step is redundant because executing it does not change the state of any variable.”
- The missing step is deliberately subtle. Students who find it without prompting demonstrate strong algorithmic analysis ability.
- Connect: “Code review and debugging in programming are exactly this activity. Every professional programmer does this daily.”
Algorithmic Thinking assessment at Class 6 must evaluate across all three cognitive levels: Follow (execution accuracy), Analyse (identification of errors and redundancy), and Apply (design and modification of algorithms). A student who executes flawlessly but cannot identify a redundant step has only partially met the LO. The rubric below reflects all three levels.
| Criterion | Level 4 — Exceeds | Level 3 — Meets | Level 2 — Approaching | Level 1 — Beginning |
|---|---|---|---|---|
| Algorithm Execution (Follow) | Executes multi-step algorithm with complete Trace Table; no steps skipped or merged; conditional branches applied correctly at every step | Executes correctly with minor documentation gaps; conditional branches applied correctly in most cases | Executes simple (linear) steps correctly; errors appear when conditional branches are encountered | Cannot execute a multi-step algorithm independently; skips steps or merges multiple steps into one |
| Error & Redundancy Detection (Analyse) | Identifies all errors and all redundant steps with clear written justification referencing the state of variables | Identifies most errors and redundancies; justification is present but may be informal | Identifies obvious errors but misses subtle redundancies; limited justification | Cannot identify errors without hints; does not distinguish necessary from redundant steps |
| State Tracking | Maintains a complete, accurate Trace Table for all variables at every step; state is always current and consistent | Trace Table mostly complete; one variable’s state is occasionally inconsistent | Records some state changes; frequently reverts to mental arithmetic for multi-variable steps | No Trace Table; relies entirely on mental tracking; state errors cascade across steps |
| Algorithm Design (Apply) | Designs a correct, minimal, unambiguous algorithm for a given task; steps are precisely worded; handles edge cases | Designs a correct algorithm with minor imprecision in language; may not be minimal but is complete | Designs a partial algorithm; key steps are present but ordering or precision is insufficient for execution by another student | Cannot independently design an algorithm; produces a list of observations rather than a procedure |
| Mathematical Language & Precision | Uses precise algorithmic vocabulary (swap, shift, increment, iterate, terminate, branch) consistently and correctly | Uses most vocabulary correctly; occasional informal substitutions | Uses informal language (“do it again,” “flip them”) that conveys intent but lacks precision | Uses no algorithmic vocabulary; instructions are ambiguous and unexecutable by a “computer” |
- Trace-to-Step-N: Give an algorithm and ask only: “What is the value/state after exactly 4 steps?” — forces correct execution without revealing the final output to copy.
- Find the Bug: Present an algorithm with one error and a known correct output. “The output should be 8 but this algorithm produces 14. Find and fix the single error.” Rapid and highly diagnostic.
- Rewrite in Fewer Steps: Give a 7-step algorithm. “Can you rewrite this in 5 steps or fewer while producing the same output?” Tests efficiency thinking without requiring original design.
- Ambiguity Audit: Give a student-written algorithm (anonymous). “Can you execute this exactly as written? Where does it become unclear?” Builds precision awareness without personal criticism.
| Misconception / Challenge | Why it happens | How to address it |
|---|---|---|
| “I don’t need to write every step — I can see the answer” | High-ability students have strong intuition and experience success without documentation on easy problems, then catastrophically fail on harder ones when mental state is lost | Make the Trace Table non-negotiable from the start. Frame it positively: “The trace table is not a crutch — it is your working memory on paper. Every professional developer uses one.” Consistently award marks for correct process even when the final answer is wrong. |
| Forgetting to update facing direction in grid movement | Students track position (row/col) but treat facing direction as implicit rather than as a separate state variable that changes with TURN instructions | Add “Facing” as a mandatory column in the Position State Tracker. Ask: “If two robots are at the same cell but facing different directions, are they in the same state?” (No.) This builds the habit of tracking all state variables. |
| Applying conditions as “or” instead of “if-then” | Students read “If even, halve; if odd, triple” and apply both operations to every term — confusing a conditional branch with a combined operation | Draw an explicit decision diamond on the board. Cover one branch at a time. “We are here. What is the value? Is it even? YES — we take this branch ONLY. We do NOT also check the odd branch.” |
| Treating a step as redundant because its result looks small or unimportant | Students judge redundancy by the magnitude of a step’s effect rather than by whether it changes the state at all | Define redundancy precisely: “A step is redundant if and only if removing it produces the same final state.” A small but necessary step is not redundant. Require written justification: “After this step, the state is ___. Before this step, the state was also ___. Therefore it is redundant.” |
| Designing algorithms that assume the reader knows context | When students write algorithms, they write for a human who shares their understanding — not for a machine that executes literally | The Algorithm Swap activity directly addresses this. After the swap, ask the author: “Did your partner execute it the way you intended?” If not: “The algorithm is wrong, not your partner.” This is the most effective way to shift the mindset. |
| Confusing the algorithm with the solution | Students think the answer to the problem IS the algorithm — they state the final output without describing the procedure that produces it | Clearly distinguish task vs algorithm: “The task asks for the answer. The CT task asks for the procedure that generates the answer. Both must be present.” Use the sentence frame: “Step 1: … Step 2: … This produces …” |
- Q: How is this different from following instructions in a Math word problem?
A: Math word problems ask for a numerical answer. CT Algorithmic Thinking tasks ask students to make the procedure itself explicit, evaluate its correctness and efficiency, and often modify or design it. The procedure is the learning object, not just the answer it produces. - Q: Should students write algorithms in pseudocode or plain language?
A: At Class 6, plain English with precise step numbering is appropriate. The key requirement is unambiguous, executable language — not programming syntax. However, introducing the IF/THEN/ELSE structure as a language convention is excellent preparation and is strongly recommended. - Q: How do I handle the Algorithm Audit activity if some students finish far faster than others?
A: The extension is built in — fast finishers write the corrected, minimal algorithm, then design their own “Algorithm Audit” for a classmate. Designing a flawed algorithm with precisely two redundancies and one ordering error requires deep understanding of the LO. - Q: How many periods are recommended for this LO?
A: 9–11 periods of 40 minutes. Suggested distribution: 2 periods on Follow (Trace Table practice across LOs 1, 3, 4) → 2 periods on Analyse (Broken Algorithm Repair, Algorithm Audit) → 2 periods on Apply (design tasks, Algorithm Swap) → 2–3 periods for mixed/integrated problems including grid navigation and multi-attribute sorting. - Q: Can the Collatz Conjecture example be used with Class 6?
A: Absolutely — and it should be. Students do not need to understand the unsolved conjecture; they only need to trace the algorithm for a given input. The revelation that a simple algorithm connects to an unsolved mathematical mystery is one of the most memorable moments possible in a CT class. Use it.
Complete this checklist after the training session to confirm readiness to teach Algorithmic Thinking (Class 6 CT).
- I can explain the three levels of Algorithmic Thinking (Follow → Analyse → Apply) and give one example task at each level.
- I can explain all 6 LO sub-areas with a worked example for each.
- I understand the difference between a redundant step and a necessary step, and can justify this distinction in writing.
- I can connect at least 3 of the 6 LO areas to a real CT or AI application.
- I can demonstrate the Trace Table method live with the Conditional Number Sequence example.
- I can facilitate the Human Computer role-play activity and lead the debrief effectively.
- I can run the Grid Navigator activity with a Position State Tracker, including the facing-direction column.
- I can facilitate the Algorithm Audit activity without revealing which steps are redundant before tracing.
- I have materials prepared for at least 3 of the 5 activities in this module.
- I can apply the 5-criterion rubric across all three levels (Follow, Analyse, Apply).
- I can design a “Trace-to-Step-N” formative question for any algorithm.
- I can explain why a student who executes correctly but cannot detect redundancy has only partially met the LO.
- I know how to scaffold Algorithm Design tasks using the Algorithm Swap peer review process.