You have chosen your CBA approach. Today you turn that choice into a plan you can actually finish: a clear scope, a few milestones, and the first piece of real work started. You will not finish the CBA today. You will leave with a plan and something underway that you can reopen next time.
This CBA checkpoint runs over two class periods, so you have about 80 minutes in total. The first half is tight planning (scope, evidence, milestones). The second half is the first milestone build or curate, with a full-class save check before the close.
Open by confirming who is on the software project path (teams of 2 to 3) and who is on the portfolio path. Seat project teams together. Where the approach was confirmed last session, students can circle Path on the template immediately and start on scope rather than admin.
Remind the class that the AI ground rules they wrote earlier still apply: what help is allowed, what must be their own work, and that any AI use is noted honestly.
Have the class saving method ready before you start (class accounts or a saved-projects folder on the school drive). Projects and portfolio folders will need to survive between sessions.
Before students write milestones, put the remaining CBA dates on the board: next progress check, final checkpoint, and presentation day. They need those anchors to space finishable milestones.
A good CBA plan answers three questions before you build or curate anything:
- What exactly am I making or collecting? One clear sentence.
- What will I have done by each checkpoint? Three milestones written so someone else could tell if you hit them.
- What could go wrong, and what is the backup? One risk and one simple backup.
Scope means cutting as much as adding. If a feature or an extra portfolio piece would make the plan unrealistic, leave it out now and note it as a stretch idea for later.
Sample: software project
Scope: A micro:bit classroom temperature logger that shows the reading on the LED screen and saves values over a lesson.
M1–M3: sensors working → logging and download working → tested with one classmate, documented and packaged.
Risk: micro:bit not available → use the online simulator and note the swap.
Sample: portfolio
Scope: Four pieces (Arcade game, website, Python list program, one studio build), each with a short learning note.
M1–M3: three pieces in one folder → short learning notes for each → checked as finished, tested and documented, then packaged cleanly.
Risk: a file is missing → rebuild a small version from notes, or swap in another saved build.
Before you write your own plan: open one piece of earlier work you already have (a saved game, website, micro:bit or Python file, or your portfolio folder if it exists). Leave it on screen so you can see what you are building on.
Walk the class through the two sample plans on screen (or the board) before students write their own. Keep the walk-through tight: point at scope, then the three done lines, then the risk and backup. The longer sample wording lives here if you need to expand verbally:
- Project sample in full: a micro:bit classroom temperature logger that shows the reading on the LED screen and saves values over a lesson. Milestones: (1) plan written and sensors working; (2) logging and download working; (3) tested with one classmate, documented and packaged. Risk: micro:bit not available → use the online simulator and note the swap in the plan.
- Portfolio sample in full: four pieces (Arcade game, website about the investigated problem, Python list program, one studio build), each with a short note on what was learnt. Milestones: (1) three pieces gathered in one folder; (2) short learning notes written for each; (3) checked against the Features of Quality (finished, tested, documented) and packaged cleanly. Risk: a file is missing → rebuild a small version from notes, or swap in another saved build and update the milestone list.
After the samples, give thirty seconds for every student to open one earlier file or folder. Real work on screen before full planning keeps attention up and makes the evidence list concrete.
Push back gently on plans that try to invent a brand-new language or a huge multiplayer game. The Features of Quality reward finished, tested, documented work over ambition that never ships.
Open the CBA plan template (one page) the class way (one shared plan per project team; one each for portfolio students). Fill in the template and save it the class way.
Sentence frame if you need it: I am making/collecting [specific product] that [one main behaviour or contents]. Example: "I am making a two-level Arcade chase game with a score and a lose condition."
Must finish in this block:
- Path (circle project or portfolio at the top).
- 1. One-sentence scope. State exactly what you are making or collecting. If you cannot say it in one sentence, the scope is still too wide. Cut until you can.
- 2. Evidence I already have. List the saved work you can draw on (game, website, micro:bit programs, Python files, earlier investigations). Note anything missing that you will need to rebuild or gather.
- 3. Three milestones. Write three checkpoints from today through to the presentation. Use the CBA dates on the board. For each one, write what "done" looks like in plain words. Example lines are on the template if you need a model. You can add a stretch milestone later after you have started building.
Mid-point check: If path, scope, evidence and three milestones are saved, open your tool or portfolio folder now and start gathering files. Do not wait for the whole class.
Finish if you have time (or in the first minutes of the build block):
- 4. One risk and one backup. Name the most likely thing that could stall you, and what you will do instead.
- 5. AI note. If you expect to use AI tools at all, write how, under the class ground rules. If you will not, write "none planned".
When you save, complete 6. Save location so you can find the plan and the project or portfolio folder next session.
Done for this block looks like:
- path chosen
- a one-sentence scope you and your teacher can understand
- evidence listed (have and missing)
- three milestones each with a clear done line
- plan saved the class way
Before you dive into building (first two minutes of the next block if needed):
- one risk and one backup
- AI note filled in or "none planned"
- save location written on the template
Suggested timing
About 14 minutes. Call a hard mid-point at roughly 8 minutes: if scope, evidence and three milestones are written, students open the tool or start gathering files while finishing any remaining lines. The mid-point checkpoint is on the student screen so it feels part of the activity.
Before they write milestones
Put the remaining CBA dates on the board: next progress check, final checkpoint, and presentation day. Students need those anchors to write three finishable milestones.
Path pre-tick
Where approach was confirmed last session, tell those students to circle Path immediately and start on section 1 (scope). Do not let path choice become a debate in this block.
Must-finish vs finish-if-time
Path plus sections 1 to 3 (scope, evidence, three milestones) are the floor for this block. Sections 4 and 5 (risk/backup, AI note) can spill into the first two minutes of the build block if a team is slow. Section 6 (save location) is completed when they save. Do not hold the whole class in planning for those last fields.
Look-fors
- Scope is specific enough to judge later (not "make a cool app").
- Milestones are ordered and finishable; the last one is packaging or presentation-ready, not "add more features".
- Project teams have agreed roles for the first stretch (who codes what, who tests, who documents).
- Portfolio students are choosing work they can actually find or rebuild, not imaginary pieces.
Teaching tips
If a team is stuck on scope, give them two minutes to list everything they want, then force a cut to half. The sentence frame is on the student screen and on the template. Example milestone lines (one project, one portfolio) are on the template under section 3. For portfolio students who cannot find earlier files, the recovery line is rebuild a small piece from their plan or notes, or swap in a different saved build they do have. Call time and move everyone into starting the work itself.
Start the first milestone on your plan. The goal is real progress you can reopen next time, not a finished CBA. If risk, backup or the AI note are still blank on your plan, fill them in the first two minutes, then build. Complete save location when you save.
If you are on the software project path:
- Open a new project in the tool you chose (Scratch, MakeCode Arcade, micro:bit, Python, or your website), or reopen the saved starting point you named in your plan.
- Build only what the first milestone asks for. Stop when that milestone's "done" line is true.
- Before you run your first test, say what you expect to see. Then test with one short run. Note one thing that already works and one thing still broken.
- Save the project the class way. Check it reopens.
If you are on the portfolio path:
- Create one portfolio folder the class way.
- Gather the first two pieces of work into it (copies or exports of saved projects, plus a short plain-text note for each: what it is, which strand it came from, and one thing you learned making it).
- If a piece is missing, rebuild a small version from memory or your old plan, or swap in another piece you do have and update your milestone list.
- Save the folder the class way. Check it reopens.
Done looks like:
- first-milestone work actually started, not only described
- at least one test or check done on what you made or gathered
- everything saved and reopened once so you know it is really there
Suggested timing
About 15 minutes. This is the hands-on heart of the lesson. Resist turning it back into planning talk. Allow the first two minutes only for anyone still finishing risk/backup, the AI note, or save location.
Predict beat (project path)
When a team is about to run their first test, ask: "What do you expect to see if milestone one is working?" Get a one-sentence prediction before they click run. Compare with the result. That is the predict-before-run moment for this lesson; it does not need its own step.
Coaching moves
- Project teams: ask "which milestone are you on right now?" If they are already on milestone three features, send them back to milestone one.
- Portfolio students: quality of the short learning note matters more than hunting for a fifth piece. Two solid pieces with honest notes beat a folder of unmarked files.
- Name debugging when it shows up: read the symptom, find the line or block, form a hypothesis, test it, revert if wrong.
Before you leave the build
Run a full-class save check three minutes before the make-sense step. Every student or team reopens what they just saved. Missing work is fixed now, not discovered at the next checkpoint.
Pull back to your plan for a moment. Which milestone did you actually start, and does your one-sentence scope still match what you are making or collecting? If the first stretch already showed the scope was too big or too vague, tighten the sentence now and adjust the later milestones. A plan that changes after contact with real work is a working plan, not a failed one.
Take two or three quick voices only: one project team whose scope shrank, one portfolio student who had to swap a missing file, one group whose first milestone is already underway. Keep it brisk. End by restating that the next checkpoint is a progress check on work that continues between sessions, not a fresh start.
Unlock the full learning experience
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.
This lesson is copyright of Coding Ireland 2017 - 2025. Unauthorised use, copying or distribution is not allowed.