← Years 9–10 Data & Information

Planning an iterative project cycle

A project done in short repeating cycles of plan, build, test and review. Feedback from each cycle is used to update the task list and schedule for the next one.

Part of: 9-10 Digital Technologies: Project management — Module 10, QCE Digital Solutions Unit 3 — Interactions Between Users, Data and Digital Systems — Module 121

Understanding Planning an iterative project cycle in Years 9–10 Data & Information

What it does: An iterative project loops through these steps again and again instead of running once from start to finish. Updating the plan means turning feedback into new or changed tasks and putting them into the next sprint. Sprints are short so the team gets feedback quickly and can change direction early. The review after each cycle is where the team collects feedback to improve the next cycle. Feedback from testing is used to update the task list so problems are fixed in later cycles. Using real results from the last cycle makes the next plan more accurate. The test step checks the work built in the sprint. Planning decides what to build, before any building happens.

Common mistakes: The cycle order is wrong. You must build something before you can test it. It should be: plan, build, test, review. A sprint is short. The end date should match the 2 week sprint length, so it should be start + 2 weeks, not 6 months.

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Planning an iterative project cycle to a class →

This module's key terms are also in a printable crossword (Modules 83–132) and word search (Modules 6–132).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
Which describes an iterative project cycle?
Plan, build, test and review, then repeatPlan once, build everything, then stop
Matches
Plan everything once -> Build for 6 months -> Test at the end
↓
This is not iterative. There is one long cycle with testing only at the end, so feedback comes too late to change the plan.
Applying
Meanings
Term
iterative project
Meaning
A project done in short repeating cycles of plan, build, test and review. Feedback from each cycle is used to update the task list and schedule for the next one.
Practice
REPEAT for each 1-week sprint
Testing
Gaps
UNTIL productdone
Check Answer
Spots
1REPEAT until app is ready
2 plan, test, build, review

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Penguin' badge — List Waddler, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. Which describes an iterative project cycle?
A. Plan once, build everything, then stop
B. Plan, build, test and review, then repeat ✓
An iterative project repeats short cycles of plan, build, test and review instead of doing everything in one pass.
2. How long is a typical sprint in an iterative project?
A. Short, such as one or two weeks ✓
B. Long, such as the whole school year
Sprints are short so the team gets feedback quickly and can change direction early.
3. A team finishes a sprint. What should they do next?
A. Start the next sprint without looking back
B. Hold a review to see what worked and what did not ✓
The review after each cycle is where the team collects feedback to improve the next cycle.
4. Testers find that a login button is confusing. What should the team do?
A. Add a task to fix it in the next sprint ✓
B. Ignore it and keep the task list the same
Feedback from testing is used to update the task list so problems are fixed in later cycles.
5. Which is true about the project schedule in an iterative project?
A. It is updated after each cycle using feedback ✓
B. It is fixed at the start and never changed
Updating the plan after each cycle keeps the schedule realistic as the team learns more.

Match the Pairs

Sprint 1: Mon-Fri → A short, fixed cycle of work (here one week) in which a small set of tasks is planned, built and tested
Sprint review → A meeting at the end of a cycle where the team shows what was built and gathers feedback
Each cycle follows the same four steps: plan, build, test and review → Plan -> Build -> Test -> Review -> repeat
Feedback from a cycle is used to update the task list for the next cycle → Review: users found login slow -> add task 'Speed up login' to Sprint 2
Plan everything once -> Build for 6 months -> Test at the end → This is not iterative. There is one long cycle with testing only at the end, so feedback comes too late to change the plan.
Sprint 1 review done -> Sprint 2 starts with the same task list → The review feedback was ignored. The task list and schedule were not updated after the cycle.

Key Term

iterative project
A project done in short repeating cycles of plan, build, test and review. Feedback from each cycle is used to update the task list and schedule for the next one.

Fill in the Blanks

1. REPEAT UNTIL product_done plan() build()
Hint: Type the keyword that makes the project cycle run again and again until the work is finished.
2. cycle: plan, build, test, review
Hint: Type the stage that comes after building and before reviewing in one cycle.
3. feedback ← review(sprint) print(feedback)
Hint: Type the name of the stage at the end of a sprint where the team collects feedback.
4. feedback ← review(sprint) update(task_list, feedback)
Hint: Type the function name that changes the task list using what the review found.
5. feedback ← review(sprint) schedule ← adjust(schedule, feedback)
Hint: Type the variable that holds what the team learned, so the schedule can be updated for the next cycle.

Spot the Error

Question 1
A REPEAT until app is ready
B plan, test, build, review
C update the task list
D END REPEAT
Line B — The cycle order is wrong. You must build something before you can test it. It should be: plan, build, test, review.
Question 2
A sprint_length <- 2 weeks
B start <- today
C sprint_end <- start + 6 months
Line C — A sprint is short. The end date should match the 2 week sprint length, so it should be start + 2 weeks, not 6 months.
Question 3
A FOR each sprint in 1 to 4
B skip review until the end
C note what to change
Line B — An iterative project holds a review after every cycle, not only at the end. It should be: hold a review meeting.
Question 4
A IF backlog is not empty
B run one short sprint
C update the backlog
D END WHILE
Line A — An iterative project repeats cycles. IF only checks once, so the sprint would run just one time. It should be WHILE so the cycles repeat.
Question 5
A feedback <- user test results
B ADD fixes to the task list
C KEEP schedule the same always
Line C — Feedback from each cycle is used to update the task list and the schedule. The schedule should be updated for the next cycle, not kept the same.

Student with a class code? Join your class →