What you'll learn
- Plan a 2-week unit with a project
- Apply backward design: results, evidence, then the learning plan
- Write a short rubric that separates functionality, quality and process
- Differentiate with supports, extensions and student choice
Plan a two-week CS unit backwards from a project, with lessons, checkpoints and differentiation.
Why it matters
A single good lesson is not enough; students learn programming through connected practice over weeks. A unitA sequence of lessons, often two to four weeks, building toward a set of outcomes, usually with a final project. is a sequence of lessons (often two to four weeks) building toward a set of outcomes, usually with a project at the end. Planning the whole unit before you start lets you sequence concepts, schedule checkpoints, prepare materials and spot problems early, instead of improvising each night.
The core idea: plan backwards from the project
Backward designPlanning that starts from desired results, then the evidence of learning, then the lessons and activities. (Wiggins and McTighe's Understanding by Design) has three stages:
- Desired results: which standards and understandings does the unit target?
- Evidence: how will students show they have reached them? (the project, checkpoints, quizzes)
- Learning plan: which lessons and activities get them there?
Projects are a natural fit for CS: students build something real, and the project itself is evidence. But a project alone is not a plan. Each lesson should teach a concept the project needs and move the project one step forward.
Anatomy of a two-week unit
| Day | Lesson focus | Project step | Check |
|---|---|---|---|
| 1 | launch: show a finished example, brief, rubricA short table of criteria and quality levels shared with students so they know what good work looks like. | brainstorm and sketch | exit ticket: what will your app do? |
| 2 | variables and input (PRIMM) | ask one question | |
| 3 | conditionals (worked example) | check the answer, keep score | Parsons problem |
| 4 | loops | ask several questions | |
| 5 | checkpointA planned mid-unit check, such as a demo or test log, that shows who is on track before the end. demo | working core in pairs | quick demo to a peer |
| 6 | functions (worked example, subgoals) | refactor into functions | |
| 7 | lists | store questions in a list | |
| 8 | testing and debugging | test plan, swap with a classmate | test log |
| 9 | polish and documentation | comments, credits, readme | |
| 10 | showcase and reflection | present and reflect | rubric self-assessment |
This structure mixes direct instruction (short, with examples), guided practice (PRIMM, Parsons) and project time, with checkpoints on days 5 and 8.
Rubrics
A clear rubric shared on day 1 tells students what quality looks like. Keep it short:
| Criterion | Beginning | Developing | Proficient |
|---|---|---|---|
| Works correctly | runs with major errors | runs; some features fail | all core features work |
| Uses functions | none | one function | logical functions with clear names |
| Tested | not tested | some tests | test log with fixes |
| Documented | no comments | some comments | comments, credits and a short readme |
Separate functionality from code quality and process, so a student whose app does less but is well tested can still show strong learning.
Differentiation
Classes include students who have coded for years and students who have never typed a bracket. Plan both ends:
- Support: starter code with the structure in place, worked examples to refer to, Parsons versions of a step, pairing.
- Extension: extra features with clear specs (a timer, a high-score table, reading questions from a file), or a "challenge card" per stage.
- Choice: let students choose the theme of their project (a quiz about their hobby, their language, their community). This supports motivation and inclusion.
Logistics that save the unit
- Accounts and tools set up and tested before day 1.
- A plan for absent students (a catch-up worked example and checklist).
- Clear submission: where, in what format, by when.
- Backup activity for when the network fails (unplugged tracing or Parsons on paper).
Common mistakes
- Project with no teaching. "Build a game" for two weeks leaves many students stuck.
- Teaching with no project link. Concepts feel disconnected if they do not appear in the project.
- No checkpoints. You discover on day 10 that half the class is lost.
- Rubric only at the end. Students cannot aim for criteria they have not seen.
- Over-ambitious scope. Plan for the middle of the class; extensions handle the rest.
Quick recap
- Plan units backwards: results, evidence, then lessons.
- Each lesson teaches a concept and moves the project forward.
- Share a short rubric on day 1 and include checkpoints mid-unit.
- Differentiate with supports, extensions and student choice; prepare logistics in advance.
Try it
Open the Do tab and plan a two-week project unit.
Key terms (5)
- unit
- A sequence of lessons, often two to four weeks, building toward a set of outcomes, usually with a final project.
- Backward design
- Planning that starts from desired results, then the evidence of learning, then the lessons and activities.
- checkpoint
- A planned mid-unit check, such as a demo or test log, that shows who is on track before the end.
- rubric
- A short table of criteria and quality levels shared with students so they know what good work looks like.
- Differentiation
- Planning supports and extensions so students with very different experience can all make progress.