Planning an iterative project cycle

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

1. Which describes an iterative project cycle?

A Plan once, build everything, then stop

B Plan, build, test and review, then repeat

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

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

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

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

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

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

Definitions

iterative project

Fill in the Blanks

Complete each line of code by filling in the missing parts.

______ UNTIL product_done plan() build()

cycle: plan, build, ____, review

feedback ← ______(sprint) print(feedback)

feedback ← review(sprint) ______(task_list, feedback)

feedback ← review(sprint) schedule ← adjust(schedule, ________)

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A REPEAT until app is ready

B plan, test, build, review

C update the task list

D END REPEAT

Question 2

A sprint_length <- 2 weeks

B start <- today

C sprint_end <- start + 6 months

Question 3

A FOR each sprint in 1 to 4

B skip review until the end

C note what to change

Question 4

A IF backlog is not empty

B run one short sprint

C update the backlog

D END WHILE

Question 5

A feedback <- user test results

B ADD fixes to the task list

C KEEP schedule the same always

Answer Key

Planning an iterative project cycle

Section A: Quick Questions

B — Plan, build, test and review, then repeat

A — Short, such as one or two weeks

B — Hold a review to see what worked and what did not

A — Add a task to fix it in the next sprint

A — It is updated after each cycle using feedback

Section B: 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.

Section C: Definitions

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.

Section D: Fill in the Blanks

REPEAT UNTIL product_done
  plan()
  build()

cycle: plan, build, test, review

feedback ← review(sprint)
print(feedback)

feedback ← review(sprint)
update(task_list, feedback)

feedback ← review(sprint)
schedule ← adjust(schedule, feedback)

Section E: Spot the Error

B — The cycle order is wrong. You must build something before you can test it. It should be: plan, build, test, review.

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.

B — An iterative project holds a review after every cycle, not only at the end. It should be: hold a review meeting.

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.

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.